Chapter 7. Sphinx Configuration

In the earlier chapters we dealt with Sphinx and learnt how it works. We created several indexes and wrote different types of search applications. While doing so we saw the most frequently used Sphinx configuration options.

In this chapter, we will see some more configuration options that will allow you to tailor Sphinx to your needs. There are numerous configuration options available to make Sphinx work exactly the way you want it to. All these are defined in the heart of Sphinx, that is, its configuration file.

Sphinx configuration file

Sphinx has to be configured before we can start using it to create indexes or search. This is done by creating a special configuration file that Sphinx reads while creating an index and searching. The configuration file can be placed anywhere in the file system. The file contains options written in a special format as follows: 

section_type1 name {
option11 = value11
option12 = value12
option13 = value13
}
section_type2 name {
option21 = value21
option22 = value22
option23 = value23
}

Each section has a name and some options, as seen in the previous code snippet. A configuration file can have the following types of sections:

  • source: Defines the source to fetch the data to be indexed
  • index: Defines the index properties such as where to save, which charset to use, and so on
  • indexer: Specifies options to be used by the indexer utility
  • searchd: Defines the properties of the search daemon, that is, the Sphinx API

Rules for creating the configuration file

What follows are the rules for creating a Sphinx configuration file:

  • The source and index sections should have a name.
  • The indexer and searchd sections should not have any name.
  • source and index can be defined multiple times in a configuration file. However, no two sources or indexes should have the same name.
  • Source and index can be extended (as done in OOP) using the colon (:) operator. An example would be source delta : main, which means that delta extends main.
  • There can only be one indexer and one searchd section in the configuration file.
  • The indexer section is optional. The searchd section is compulsory when using the client API. The source and index sections are compulsory.
  • Section names can only have letters, numbers, hyphens, and underscores. No spaces.
  • You can use # to write single line comments.
  • You can give any name to your configuration file and save it anywhere on your file system. However, it is a good practice to save all configurations in a single directory.

Let's take a look at a few valid and invalid configuration files:

# Valid configuration file
source blog {
= mysql
sql_query = SELECT id, name FROM users
#...
}
index blog {
source = blog
path = /path/to/save/index
}
source childblog : blog {
sql_query = SELECT id, name FROM users WHERE id > 40
}
index childblog : blog {
source = childblog
path = /path/to/save/childindex
}
indexer {
mem_limit = 32M
}
searchd {
listen = localhost:9312
}

Note

Don't worry about the options inside each section. We will take a look at them later in this chapter

The next configuration file is invalid and Sphinx will throw errors when you try to create the index. 

source blog app {
#...
}
index blog {
#...
}
index blog {
#...
}
searchd blog-daemon {
#...
}

The following errors can be found in the configuration file:

  • source name contains spaces
  • Two indexes have the same name
  • searchd has a name

    Tip

    If you are developing a web application, save your configuration file outside the webroot. It is recommended to save it in a directory that is not world readable.

Now that we know how to create a Sphinx configuration file and basic rules to create the configuration sections, let's proceed and see what different options can be specified in each section.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset