1.1. About Sphinx is a full-text search engine, publicly distributed under GPL version 2. Commercial licensing (eg. For embedded use) is available upon request. Technically, Sphinx is a standalone software package provides fast and relevant full-text search functionality to client applications. It was specially designed to integrate well with SQL databases storing the data, and to be easily accessed by scripting languages. However, Sphinx does not depend on nor require any specific database to function. Applications can access Sphinx search daemon (searchd) using any of the three different access methods: a) via Sphinx own implementation of MySQL network protocol (using a small SQL subset called SphinxQL, this is recommended way), b) via native search API (SphinxAPI) or c) via MySQL server with a pluggable storage engine (SphinxSE).

Official native SphinxAPI implementations for PHP, Perl, Python, Ruby and Java are included within the distribution package. API is very lightweight so porting it to a new language is known to take a few hours or days. Download Naruto Shippuden Episode 174 Sub Indo 3gp.

Latest trending topics being covered on ZDNet including Reviews, Tech Industry, Security, Hardware, Apple, and Windows.

Third party API ports and plugins exist for Perl, C#, Haskell, Ruby-on-Rails, and possibly other languages and frameworks. Starting from version 1.10-beta, Sphinx supports two different indexing backends: 'disk' index backend, and 'realtime' (RT) index backend. Disk indexes support online full-text index rebuilds, but online updates can only be done on non-text (attribute) data.

RT indexes additionally allow for online full-text index updates. Previous versions only supported disk indexes.

Data can be loaded into disk indexes using a so-called data source. Built-in sources can fetch data directly from MySQL, PostgreSQL, MSSQL, ODBC compliant database (Oracle, etc) or a pipe in TSV or a custom XML format. Adding new data sources drivers (eg. To natively support other DBMSes) is designed to be as easy as possible. RT indexes, as of 1.10-beta, can only be populated using SphinxQL.

As for the name, Sphinx is an acronym which is officially decoded as SQL Phrase Index. Yes, I know about CMU's Sphinx project. • high indexing and searching performance; • advanced indexing and querying tools (flexible and feature-rich text tokenizer, querying language, several different ranking modes, etc); • advanced result set post-processing (SELECT with expressions, WHERE, ORDER BY, GROUP BY, HAVING etc over text search results); • proven scalability up to billions of documents, terabytes of data, and thousands of queries per second; • easy integration with SQL and XML data sources, and SphinxQL, SphinxAPI, or SphinxSE search interfaces; • easy scaling with distributed searches. To expand a bit, Sphinx. • indexer: an utility which creates fulltext indexes; • searchd: a daemon which enables external software (eg. Web applications) to search through fulltext indexes; • sphinxapi: a set of searchd client API libraries for popular Web scripting languages (PHP, Python, Perl, Ruby). • spelldump: a simple command-line tool to extract the items from an ispell or MySpell (as bundled with OpenOffice) format dictionary to help customize your index, for use with.

• indextool: an utility to dump miscellaneous debug information about the index, added in version 0.9.9-rc2. • wordbreaker: an utility to break down compound words into separate words, added in version 2.1.1. 1.4. License This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. See COPYING file for details. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA USA Non-GPL licensing (for OEM/ISV embedded use) can also be arranged, please to discuss commercial licensing possibilities. • Linux 2.4.x, 2.6.x, 3.x (many various distributions) • Windows 2000, XP, 7, 8 • FreeBSD 4.x, 5.x, 6.x, 7.x, 8.x • NetBSD 1.6, 3.0 • Solaris 9, 11 • Mac OS X CPU architectures known to work include i386 (aka x86), amd64 (aka x86_64), SPARC64, and ARM. Chances are good that Sphinx should work on other Unix platforms and/or CPU architectures just as well. Please report any other platforms that worked for you! All platforms are production quality. There are no principal functional limitations on any platform.

• --prefix, which specifies where to install Sphinx; such as --prefix=/usr/local/sphinx (all of the examples use this prefix) • --with-mysql, which specifies where to look for MySQL include and library files, if auto-detection fails; • --with-static-mysql, which builds Sphinx with statically linked MySQL support; • --with-pgsql, which specifies where to look for PostgreSQL include and library files. • --with-static-pgsql, which builds Sphinx with statically linked PostgreSQL support; • Build the binaries. 2.2.3. Known compilation issues If configure fails to locate MySQL headers and/or libraries, try checking for and installing mysql-devel package. On some systems, it is not installed by default. If make fails with a message which look like /bin/sh: g++: command not found make[1]: *** [libsphinx_a-sphinx.o] Error 127 try checking for and installing gcc-c++ package.

If you are getting compile-time errors which look like sphinx.cpp:67: error: invalid application of `sizeof' to incomplete type `Private::SizeError' this means that some compile-time type size check failed. The most probable reason is that off_t type is less than 64-bit on your system. As a quick hack, you can edit sphinx.h and replace off_t with DWORD in a typedef for SphOffset_t, but note that this will prohibit you from using full-text indexes larger than 2 GB. Even if the hack helps, please report such issues, providing the exact error message and compiler/OS details, so I could properly fix them in next releases.

If you keep getting any other error, or the suggestions above do not seem to help you, please don't hesitate to contact me. • Extract everything from the.zip file you have downloaded - sphinx-2.2.11-dev-win32.zip, or sphinx-2.2.11-dev-win32-pgsql.zip if you need PostgresSQL support as well. (We are using version 2.2.11-dev here for the sake of example only; be sure to change this to a specific version you're using.) You can use Windows Explorer in Windows XP and up to extract the files, or a freeware package like 7Zip to open the archive. For the remainder of this guide, we will assume that the folders are unzipped into C: Sphinx, such that searchd.exe can be found in C: Sphinx bin searchd.exe.

If you decide to use any different location for the folders or configuration file, please change it accordingly. • Edit the contents of sphinx.conf.in - specifically entries relating to @CONFDIR@ - to paths suitable for your system.

• Install the searchd system as a Windows service: C: Sphinx bin>C: Sphinx bin searchd --install --config C: Sphinx sphinx.conf.in --servicename SphinxSearch • The searchd service will now be listed in the Services panel within the Management Console, available from Administrative Tools. It will not have been started, as you will need to configure it and build your indexes with indexer before starting the service.

A guide to do this can be found under. During the next steps of the install (which involve running indexer pretty much as you would on Linux) you may find that you get an error relating to libmysql.dll not being found. If you have MySQL installed, you should find a copy of this library in your Windows directory, or sometimes in Windows System32, or failing that in the MySQL core directories. If you do receive an error please copy libmysql.dll into the bin directory. • 32-bit document IDs are now deprecated. Our binary releases are now all built with 64-bit IDs by default.

Note that they can still load older indexes with 32-bit IDs, but that support will eventually be removed. In fact, that was deprecated awhile ago, but now we just want to make it clear: we don't see any sense in trying to save your server's RAM this way. • dict=crc is now deprecated. It has a bunch of limitations, the most important ones being keyword collisions, and no (good) wildcard matching support. You can read more about those limitations in our documentation. • charset_type=sbcs is now deprecated, we're slowly switching to UTF-only. Even if your database is SBCS (likely for legacy reasons too, eh?), this should be absolutely trivial to workaround, just add a pre-query to fetch your data in UTF-8 and you're all set.

Also, in fact, our current UTF-8 tokenizer is even faster than the SBCS one. • custom sort (@custom) is now removed from Sphinx. This feature was introduced long before sort by expression became a reality and it has been deprecated for a very long time. • enable_star is deprecated now. Previous default mode was enable_star=0 which was due to compatibility with a very old Sphinx version. Such implicit star search isn't very intuitive. So, we've decided to eventually remove it and have marked it as deprecated just recently.

We plan to totally remove this configuration key in the 2.2.X branch. • str2ordinal attributes are deprecated. This feature allows you to perform sorting by a string. But it's also possible to do this with ordinary string attributes, which is much easier to use. Str2ordinal only covers a small part of this functionality and is not needed now. • str2wordcount attributes are deprecated.

Will create an integer attribute with field length set automatically and we recommend to use this configuration key when you need to store field lengths. Also, index_field_lengths=1 allows you to use new ranking formulas like BM25F(). • hit_format is deprecated.

This is a hidden configuration key - it's not mentioned in our documentation. But, it's there and it's possible that someone may use it.

And now we're urging you: don't use it. The default value is 'inline' and it's a new standard. 'plain' hit_format is obsolete and will be removed in the near future. • docinfo=inline is deprecated. You can now use or instead.

• workers=threads is a new default for all OS now. We're gonna get rid of other modes in future. • mem_limit=128M is a new default. • rt_mem_limit=128M is a new default.

• ondisk_dict is deprecated. No need to save RAM this way. • ondisk_dict_default is deprecated. No need to save RAM this way.

• compat_sphinxql_magics was removed. Now you can't use an old result format and SphinxQL always looks more like ANSI SQL.

• Completely removed xmlpipe. This was a very old ad hoc solution for a particular customer. Xmlpipe2 surpasses it in every single aspect.

None of the different querying methods are deprecated, but as of version 2.2.1-beta, SphinxQL is the most advanced method. We plan to remove SphinxAPI and Sphinx SE someday so it would be a good idea to start using SphinxQL. • Removed deprecated 'address' and 'port' directives. Use 'listen' instead.

• Removed str2wordcount attributes. • Removed str2ordinal attributes. Use string attributes for sorting. • ondisk_dict and ondisk_dict_default was removed. • Removed charset_type and mssql_unicode - we now support only UTF-8 encoding. • Removed deprecated enable_star. Now always work as with enable_star=1.

• Removed CLI search which confused people instead of helping them and sql_query_info. • Deprecated SetMatchMode() API call. • Changed default value to 1M. • Deprecated SetOverride() API call.

Changes for 2.2.3-beta. 3.1. Data sources The data to be indexed can generally come from very different sources: SQL databases, plain text files, HTML files, mailboxes, and so on. From Sphinx point of view, the data it indexes is a set of structured documents, each of which has the same set of fields and attributes.

This is similar to SQL, where each row would correspond to a document, and each column to either a field or an attribute. Depending on what source Sphinx should get the data from, different code is required to fetch the data and prepare it for indexing. This code is called data source driver (or simply driver or data source for brevity). At the time of this writing, there are built-in drivers for MySQL, PostgreSQL, MS SQL (on Windows), and ODBC. There is also a generic driver called xmlpipe2, which runs a specified command and reads the data from its stdout. See section for the format description. In 2.2.1-beta a tsvpipe (Tab Separated Values) and csvpipe (Comma Separated Values) data source was added.

You can get more information here. There can be as many sources per index as necessary. They will be sequentially processed in the very same order which was specified in index definition.

All the documents coming from those sources will be merged as if they were coming from a single source. 3.2. Full-text fields Full-text fields (or just fields for brevity) are the textual document contents that get indexed by Sphinx, and can be (quickly) searched for keywords. Fields are named, and you can limit your searches to a single field (eg. Search through 'title' only) or a subset of fields (eg. To 'title' and 'abstract' only). Sphinx index format generally supports up to 256 fields.

However, up to version 2.0.1-beta indexes were forcibly limited by 32 fields, because of certain complications in the matching engine. Full support for up to 256 fields was added in version 2.0.2-beta. Note that the original contents of the fields are not stored in the Sphinx index. The text that you send to Sphinx gets processed, and a full-text index (a special data structure that enables quick searches for a keyword) gets built from that text. But the original text contents are then simply discarded. Sphinx assumes that you store those contents elsewhere anyway.

Moreover, it is impossible to fully reconstruct the original text, because the specific whitespace, capitalization, punctuation, etc will all be lost during indexing. It is theoretically possible to partially reconstruct a given document from the Sphinx full-text index, but that would be a slow process (especially if the is used, which does not even store the original keywords and works with their hashes instead). 3.3. Attributes Attributes are additional values associated with each document that can be used to perform additional filtering and sorting during search. It is often desired to additionally process full-text search results based not only on matching document ID and its rank, but on a number of other per-document values as well. For instance, one might need to sort news search results by date and then relevance, or search through products within specified price range, or limit blog search to posts made by selected users, or group results by month. To do that efficiently, Sphinx allows to attach a number of additional attributes to each document, and store their values in the full-text index.

It's then possible to use stored values to filter, sort, or group full-text matches. Attributes, unlike the fields, are not full-text indexed.

They are stored in the index, but it is not possible to search them as full-text, and attempting to do so results in an error. For example, it is impossible to use the extended matching mode expression @column 1 to match documents where column is 1, if column is an attribute, and this is still true even if the numeric digits are normally indexed. Attributes can be used for filtering, though, to restrict returned rows, as well as sorting or; it is entirely possible to sort results purely based on attributes, and ignore the search relevance tools. Additionally, attributes are returned from the search daemon, while the indexed text is not. A good example for attributes would be a forum posts table. Assume that only title and content fields need to be full-text searchable - but that sometimes it is also required to limit search to a certain author or a sub-forum (ie. Search only those rows that have some specific values of author_id or forum_id columns in the SQL table); or to sort matches by post_date column; or to group matching posts by month of the post_date and calculate per-group match counts.

This can be achieved by specifying all the mentioned columns (excluding title and content, that are full-text fields) as attributes, indexing them, and then using API calls to setup filtering, sorting, and grouping. Here as an example. Example sphinx.conf part. Sql_query = SELECT id, title, content, author_id, forum_id, post_date FROM my_forum_posts sql_attr_uint = author_id sql_attr_uint = forum_id sql_attr_timestamp = post_date. Example application code (in PHP): // only search posts by author whose ID is 123 $cl->SetFilter ( 'author_id', array ( 123 ) ); // only search posts in sub-forums 1, 3 and 7 $cl->SetFilter ( 'forum_id', array ( 1,3,7 ) ); // sort found posts by posting date in descending order $cl->SetSortMode ( SPH_SORT_ATTR_DESC, 'post_date' ); Attributes are named. Attribute names are case insensitive. Attributes are not full-text indexed; they are stored in the index as is.

Currently supported attribute types are. • stored separately from the main full-text index data ('extern' storage, in.spa file), or • attached to each occurrence of document ID in full-text index data ('inline' storage, in.spd file). When using extern storage, a copy of.spa file (with all the attribute values for all the documents) is kept in RAM by searchd at all times. This is for performance reasons; random disk I/O would be too slow. On the contrary, inline storage does not require any additional RAM at all, but that comes at the cost of greatly inflating the index size: remember that it copies all attribute value every time when the document ID is mentioned, and that is exactly as many times as there are different keywords in the document.

Inline may be the only viable option if you have only a few attributes and need to work with big datasets in limited RAM. However, in most cases extern storage makes both indexing and searching much more efficient. Search-time memory requirements for extern storage are (1+number_of_attrs)*number_of_docs*4 bytes, ie. 10 million docs with 2 groups and 1 timestamp will take (1+2+1)*10M*4 = 160 MB of RAM. This is PER DAEMON, not per query. Searchd will allocate 160 MB on startup, read the data and keep it shared between queries.

The children will NOT allocate any additional copies of this data. 3.4. MVA (multi-valued attributes) MVAs, or multi-valued attributes, are an important special type of per-document attributes in Sphinx. MVAs let you attach sets of numeric values to every document. That is useful to implement article tags, product categories, etc. Filtering and group-by (but not sorting) on MVA attributes is supported. As of version 2.0.2-beta, MVA values can either be unsigned 32-bit integers (UNSIGNED INTEGER) or signed 64-bit integers (BIGINT). Up to version 2.0.1-beta, only the unsigned 32-bit values were supported.

The set size is not limited, you can have an arbitrary number of values attached to each document as long as RAM permits (.spm file that contains the MVA values will be precached in RAM by searchd). The source data can be taken either from a separate query, or from a document field; see source type in. In the first case the query will have to return pairs of document ID and MVA values, in the second one the field will be parsed for integer values. There are absolutely no requirements as to incoming data order; the values will be automatically grouped by document ID (and internally sorted within the same ID) during indexing anyway. When filtering, a document will match the filter on MVA attribute if any of the values satisfy the filtering condition.

(Therefore, documents that pass through exclude filters will not contain any of the forbidden values.) When grouping by MVA attribute, a document will contribute to as many groups as there are different MVA values associated with that document. For instance, if the collection contains exactly 1 document having a 'tag' MVA with values 5, 7, and 11, grouping on 'tag' will produce 3 groups with 'COUNT(*)' equal to 1 and 'GROUPBY()' key values of 5, 7, and 11 respectively. Also note that grouping by MVA might lead to duplicate documents in the result set: because each document can participate in many groups, it can be chosen as the best one in in more than one group, leading to duplicate IDs. PHP API historically uses ordered hash on the document ID for the resulting rows; so you'll also need to use in order to employ group-by on MVA with PHP API. 3.5. Indexes To be able to answer full-text search queries fast, Sphinx needs to build a special data structure optimized for such queries from your text data.

This structure is called index; and the process of building index from text is called indexing. Different index types are well suited for different tasks. For example, a disk-based tree-based index would be easy to update (ie. Insert new documents to existing index), but rather slow to search. Sphinx architecture allows internally for different index types, or backends, to be implemented comparatively easily.

Starting with 1.10-beta, Sphinx provides 2 different backends: a disk index backend, and a RT (realtime) index backend. Disk indexes are designed to provide maximum indexing and searching speed, while keeping the RAM footprint as low as possible. That comes at a cost of text index updates. You can not update an existing document or incrementally add a new document to a disk index.

You only can batch rebuild the entire disk index from scratch. (Note that you still can update document's attributes on the fly, even with the disk indexes.) This 'rebuild only' limitation might look as a big constraint at a first glance. But in reality, it can very frequently be worked around rather easily by setting up multiple disk indexes, searching through them all, and only rebuilding the one with a fraction of the most recently changed data. See for details.

RT indexes enable you to implement dynamic updates and incremental additions to the full text index. RT stands for Real Time and they are indeed 'soft realtime' in terms of writes, meaning that most index changes become available for searching as quick as 1 millisecond or less, but could occasionally stall for seconds.

(Searches will still work even during that occasional writing stall.) Refer to for details. Last but not least, Sphinx supports so-called distributed indexes. Compared to disk and RT indexes, those are not a real physical backend, but rather just lists of either local or remote indexes that can be searched transparently to the application, with Sphinx doing all the chores of sending search requests to remote machines in the cluster, aggregating the result sets, retrying the failed requests, and even doing some load balancing. See for a discussion of distributed indexes. There can be as many indexes per configuration file as necessary.

Indexer utility can reindex either all of them (if --all option is specified), or a certain explicitly specified subset. Searchd utility will serve all the specified indexes, and the clients can specify what indexes to search in run time.

3.6. Restrictions on the source data There are a few different restrictions imposed on the source data which is going to be indexed by Sphinx, of which the single most important one is: ALL DOCUMENT IDS MUST BE UNIQUE UNSIGNED NON-ZERO INTEGER NUMBERS (32-BIT OR 64-BIT, DEPENDING ON BUILD TIME SETTINGS). If this requirement is not met, different bad things can happen.

For instance, Sphinx can crash with an internal assertion while indexing; or produce strange results when searching due to conflicting IDs. Also, a 1000-pound gorilla might eventually come out of your display and start throwing barrels at you. You've been warned. • what encoding is the source text in (and this encoding should always be UTF-8); • what characters are letters and what are not; • what letters should be folded to what letters. This should be configured on a per-index basis using option. Specifies the table that maps letter characters to their case folded versions. The characters that are not in the table are considered to be non-letters and will be treated as word separators when indexing or searching through this index.

Default tables currently include English and Russian characters. Please do submit your tables for other languages! As of version 2.1.1-beta, you can also specify text pattern replacement rules. For example, given the rules regexp_filter = b( d+) ' =>1 inch regexp_filter = (BLUE RED) =>COLOR the text 'RED TUBE 5' LONG' would be indexed as 'COLOR TUBE 5 INCH LONG', and 'PLANK 2' x 4' as 'PLANK 2 INCH x 4 INCH'. Rules are applied in the given order. Text in queries is also replaced; a search for 'BLUE TUBE' would actually become a search for 'COLOR TUBE'. Note that Sphinx must be built with the --with-re2 option to use this feature.

• with $start replaced with 1 and $end replaced with 1000; • with $start replaced with 1001 and $end replaced with 2000; • with $start replaced with 2001 and $end replaced with 2345. Obviously, that's not much of a difference for 2000-row table, but when it comes to indexing 10-million-row MyISAM table, ranged queries might be of some help. Sql_query_post vs. Sql_query_post_index The difference between post-query and post-index query is in that post-query is run immediately when Sphinx received all the documents, but further indexing may still fail for some other reason.

On the contrary, by the time the post-index query gets executed, it is guaranteed that the indexing was successful. Database connection is dropped and re-established because sorting phase can be very lengthy and would just timeout otherwise. This is the main content entry must be handled properly by xml parser lib]]>note how field/attr tags can be in randomized order some undeclared element another subject here comes another document, and i am given to understand, that in-document field order must not matter, sir 1234 4567 Arbitrary fields and attributes are allowed. They also can occur in the stream in arbitrary order within each document; the order is ignored. There is a restriction on maximum field length; fields longer than 2 MB will be truncated to 2 MB (this limit can be changed in the source). The schema, ie. Complete fields and attributes list, must be declared before any document could be parsed.

This can be done either in the configuration file using xmlpipe_field and xmlpipe_attr_XXX settings, or right in the stream using element. It is only allowed to occur as the very first sub-element in. If there is no in-stream schema definition, settings from the configuration file will be used. Otherwise, stream settings take precedence.

Unknown tags (which were not declared neither as fields nor as attributes) will be ignored with a warning. In the example above, will be ignored. All embedded tags and their attributes (such as in in the example above) will be silently ignored. Support for incoming stream encodings depends on whether iconv is installed on the system. Xmlpipe2 is parsed using libexpat parser that understands US-ASCII, ISO-8859-1, UTF-8 and a few UTF-16 variants natively.

Sphinx configure script will also check for libiconv presence, and utilize it to handle other encodings. Libexpat also enforces the requirement to use UTF-8 charset on Sphinx side, because the parsed data it returns is always in UTF-8. XML elements (tags) recognized by xmlpipe2 (and their attributes where applicable) are.

• 'name', specifies the element name that should be treated as an attribute in the subsequent documents. • 'type', specifies the attribute type. Possible values are 'int', 'bigint', 'timestamp', 'bool', 'float', 'multi' and 'json'. • 'bits', specifies the bit size for 'int' attribute type. Valid values are 1 to 32. • 'default', specifies the default value for this attribute that should be used if the attribute's element is not present in the document. Sphinx:document Mandatory element, must be a child of sphinx:docset.

Contains arbitrary other elements with field and attribute values to be indexed, as declared either using sphinx:field and sphinx:attr elements or in the configuration file. The only known attribute is 'id' that must contain the unique integer document ID. Sphinx:killlist Optional element, child of sphinx:docset. Contains a number of 'id' elements whose contents are document IDs to be put into a for this index. 3.10. tsvpipe csvpipe (Tab Comma Separated Values) data source This is the simplest way to pass data to the indexer. It was created due to xmlpipe2 limitations.

Namely, indexer must map each attribute and field tag in XML file to corresponding schema element. This mapping requires some time. And time increases with increasing the number of fields and attributes in schema. There is no such issue in tsvpipe because each field and attribute is a particular column in TSV file. So, in some cases tsvpipe could work slightly faster than xmlpipe2. Added in 2.2.1-beta. The first column in TSV CSV file must be a document ID.

The rest ones must mirror the declaration of fields and attributes in schema definition. How To Install A Cable Modem Connection on this page. The difference between tsvpipe and csvpipe is delimiter and quoting rules. Tsvpipe has tab character as hardcoded delimiter and has no quoting rules.

Csvpipe has option for delimiter with default value ',' and also has quoting rules, such as. 3.11. Live index updates There are two major approaches to maintaining the full-text index contents up to date. Note, however, that both these approaches deal with the task of full-text data updates, and not attribute updates.

Instant attribute updates are supported since version 0.9.8. Refer to API call description for details. First, you can use disk-based indexes, partition them manually, and only rebuild the smaller partitions (so-called 'deltas') frequently. By minimizing the rebuild size, you can reduce the average indexing lag to something as low as 30-60 seconds. This approach was the only one available in versions 0.9.x.

On huge collections it actually might be the most efficient one. Refer to for details. Second, versions 1.x (starting with 1.10-beta) add support for so-called real-time indexes (RT indexes for short) that on-the-fly updates of the full-text data. Updates on a RT index can appear in the search results in 1-2 milliseconds, ie. 0.001-0.002 seconds. However, RT index are less efficient for bulk indexing huge amounts of data.

Refer to for details. 3.12. Delta index updates There's a frequent situation when the total dataset is too big to be reindexed from scratch often, but the amount of new records is rather small. Example: a forum with a 1,000,000 archived posts, but only 1,000 new posts per day. In this case, 'live' (almost real time) index updates could be implemented using so called 'main+delta' scheme.

The idea is to set up two sources and two indexes, with one 'main' index for the data which only changes rarely (if ever), and one 'delta' for the new documents. In the example above, 1,000,000 archived posts would go to the main index, and newly inserted 1,000 posts/day would go to the delta index. Delta index could then be reindexed very frequently, and the documents can be made available to search in a matter of minutes. Specifying which documents should go to what index and reindexing main index could also be made fully automatic. One option would be to make a counter table which would track the ID which would split the documents, and update it whenever the main index is reindexed. 3.13. Index merging Merging two existing indexes can be more efficient than indexing the data from scratch, and desired in some cases (such as merging 'main' and 'delta' indexes instead of simply reindexing 'main' in 'main+delta' partitioning scheme).

So indexer has an option to do that. Merging the indexes is normally faster than reindexing but still not instant on huge indexes. Basically, it will need to read the contents of both indexes once and write the result once. Merging 100 GB and 1 GB index, for example, will result in 202 GB of IO (but that's still likely less than the indexing from scratch requires). The basic command syntax is as follows: indexer --merge DSTINDEX SRCINDEX [--rotate] Only the DSTINDEX index will be affected: the contents of SRCINDEX will be merged into it.

--rotate switch will be required if DSTINDEX is already being served by searchd. The initially devised usage pattern is to merge a smaller update from SRCINDEX into DSTINDEX. Thus, when merging the attributes, values from SRCINDEX will win if duplicate document IDs are encountered. Note, however, that the 'old' keywords will not be automatically removed in such cases. For example, if there's a keyword 'old' associated with document 123 in DSTINDEX, and a keyword 'new' associated with it in SRCINDEX, document 123 will be found by both keywords after the merge.

You can supply an explicit condition to remove documents from DSTINDEX to mitigate that; the relevant switch is --merge-dst-range: indexer --merge main delta --merge-dst-range deleted 0 0 This switch lets you apply filters to the destination index along with merging. There can be several filters; all of their conditions must be met in order to include the document in the resulting merged index. In the example above, the filter passes only those records where 'deleted' is 0, eliminating all records that were flagged as deleted (for instance, using call). • Default conservative RAM chunk limit ( rt_mem_limit) of 32M can lead to poor performance on bigger indexes, you should raise it to 256.1024M if you're planning to index gigabytes. • High DELETE/REPLACE rate can lead to kill-list fragmentation and impact searching performance. • No transaction size limits are currently imposed; too many concurrent INSERT/REPLACE transactions might therefore consume a lot of RAM. • In case of a damaged binlog, recovery will stop on the first damaged transaction, even though it's technically possible to keep looking further for subsequent undamaged transactions, and recover those.

This mid-file damage case (due to flaky HDD/CDD/tape?) is supposed to be extremely rare, though. • Multiple INSERTs grouped in a single transaction perform better than equivalent single-row transactions and are recommended for batch loading of data.

4.3. RT index internals RT index is internally chunked. It keeps a so-called RAM chunk that stores all the most recent changes. RAM chunk memory usage is rather strictly limited with per-index directive. Once RAM chunk grows over this limit, a new disk chunk is created from its data, and RAM chunk is reset. Thus, while most changes on the RT index will be performed in RAM only and complete instantly (in milliseconds), those changes that overflow the RAM chunk will stall for the duration of disk chunk creation (a few seconds). Since version 2.1.1-beta, Sphinx uses double-buffering to avoid INSERT stalls. When data is being dumped to disk, the second buffer is used, so further INSERTs won't be delayed.

The second buffer is defined to be 10% the size of the standard buffer,, but future versions of Sphinx may allow configuring this further. Disk chunks are, in fact, just regular disk-based indexes. But they're a part of an RT index and automatically managed by it, so you need not configure nor manage them manually. Because a new disk chunk is created every time RT chunk overflows the limit, and because in-memory chunk format is close to on-disk format, the disk chunks will be approximately rt_mem_limit bytes in size each.

Generally, it is better to set the limit bigger, to minimize both the frequency of flushes, and the index fragmentation (number of disk chunks). For instance, on a dedicated search server that handles a big RT index, it can be advised to set rt_mem_limit to 1-2 GB. A global limit on all indexes is also planned, but not yet implemented yet as of 1.10-beta.

Disk chunk full-text index data can not be actually modified, so the full-text field changes (ie. Row deletions and updates) suppress a previous row version from a disk chunk using a kill-list, but do not actually physically purge the data. Therefore, on workloads with high full-text updates ratio index might eventually get polluted by these previous row versions, and searching performance would degrade. Physical index purging that would improve the performance is planned, but not yet implemented as of 1.10-beta. Data in RAM chunk gets saved to disk on clean daemon shutdown, and then loaded back on startup. However, on daemon or server crash, updates from RAM chunk might be lost. To prevent that, binary logging of transactions can be used; see for details.

Full-text changes in RT index are transactional. They are stored in a per-thread accumulator until COMMIT, then applied at once. Bigger batches per single COMMIT should result in faster indexing. 4.4. Binary logging Binary logs are essentially a recovery mechanism. With binary logs enabled, searchd writes every given transaction to the binlog file, and uses that for recovery after an unclean shutdown. On clean shutdown, RAM chunks are saved to disk, and then all the binlog files are unlinked.

During normal operation, a new binlog file will be opened every time when binlog_max_log_size limit is reached. Older, already closed binlog files are kept until all of the transactions stored in them (from all indexes) are flushed as a disk chunk. Setting the limit to 0 pretty much prevents binlog from being unlinked at all while searchd is running; however, it will still be unlinked on clean shutdown. (This is the default case as of 2.0.3-release, binlog_max_log_size defaults to 0.) There are 3 different binlog flushing strategies, controlled by directive which takes the values of 0, 1, or 2. 0 means to flush the log to OS and sync it to disk every second; 1 means flush and sync every transaction; and 2 (the default mode) means flush every transaction but sync every second.

Sync is relatively slow because it has to perform physical disk writes, so mode 1 is the safest (every committed transaction is guaranteed to be written on disk) but the slowest. Flushing log to OS prevents from data loss on searchd crashes but not system crashes.

Mode 2 is the default. On recovery after an unclean shutdown, binlogs are replayed and all logged transactions since the last good on-disk state are restored. Transactions are checksummed so in case of binlog file corruption garbage data will not be replayed; such a broken transaction will be detected and, currently, will stop replay. Transactions also start with a magic marker and timestamped, so in case of binlog damage in the middle of the file, it's technically possible to skip broken transactions and keep replaying from the next good one, and/or it's possible to replay transactions until a given timestamp (point-in-time recovery), but none of that is implemented yet as of 1.10-beta. One unwanted side effect of binlogs is that actively updating a small RT index that fully fits into a RAM chunk part will lead to an ever-growing binlog that can never be unlinked until clean shutdown. Binlogs are essentially append-only deltas against the last known good saved state on disk, and unless RAM chunk gets saved, they can not be unlinked. An ever-growing binlog is not very good for disk use and crash recovery time.

Starting with 2.0.1-beta you can configure searchd to perform a periodic RAM chunk flush to fix that problem using a directive. With periodic flushes enabled, searchd will keep a separate thread, checking whether RT indexes RAM chunks need to be written back to disk.

Once that happens, the respective binlogs can be (and are) safely unlinked. Note that rt_flush_period only controls the frequency at which the checks happen. There are no guarantees that the particular RAM chunk will get saved. For instance, it does not make sense to regularly re-save a huge RAM chunk that only gets a few rows worth of updates. The search daemon determine whether to actually perform the flush with a few heuristics. 5.1. Matching modes So-called matching modes are a legacy feature that used to provide (very) limited query syntax and ranking support. Currently, they are deprecated in favor of and so-called.

Starting with version 0.9.9-release, it is thus strongly recommended to use SPH_MATCH_EXTENDED and proper query syntax rather than any other legacy mode. All those other modes are actually internally converted to extended syntax anyway. SphinxAPI still defaults to SPH_MATCH_ALL but that is for compatibility reasons only. There are the following matching modes available. • SPH_MATCH_ALL, matches all query words; • SPH_MATCH_ANY, matches any of the query words; • SPH_MATCH_PHRASE, matches query as a phrase, requiring perfect match; • SPH_MATCH_BOOLEAN, matches query as a boolean expression (see ); • SPH_MATCH_EXTENDED, matches query as an expression in Sphinx internal query language (see ); • SPH_MATCH_EXTENDED2, an alias for SPH_MATCH_EXTENDED (default mode); • SPH_MATCH_FULLSCAN, matches query, forcibly using the 'full scan' mode as below. NB, any query terms will be ignored, such that filters, filter-ranges and grouping will still be applied, but no text-matching.

SPH_MATCH_EXTENDED2 was used during 0.9.8 and 0.9.9 development cycle, when the internal matching engine was being rewritten (for the sake of additional functionality and better performance). By 0.9.9-release, the older version was removed, and SPH_MATCH_EXTENDED and SPH_MATCH_EXTENDED2 are now just aliases. The SPH_MATCH_FULLSCAN mode will be automatically activated in place of the specified matching mode when the following conditions are met.

• The query string is empty (ie. Its length is zero). • storage is set to extern. In full scan mode, all the indexed documents will be considered as matching. Such queries will still apply filters, sorting, and group by, but will not perform any full-text searching. This can be useful to unify full-text and non-full-text searching code, or to offload SQL server (there are cases when Sphinx scans will perform better than analogous MySQL queries). An example of using the full scan mode might be to find posts in a forum.

By selecting the forum's user ID via SetFilter() but not actually providing any search text, Sphinx will match every document (i.e. Every post) where SetFilter() would match - in this case providing every post from that user. By default this will be ordered by relevancy, followed by Sphinx document ID in ascending order (earliest first). • Find the words 'hello' and 'world' adjacently in any field in a document; • Additionally, the same document must also contain the words 'example' and 'program' in the title field, with up to, but not including, 5 words between the words in question; (E.g.

'example PHP program' would be matched however 'example script to introduce outside data into the correct context for your program' would not because two terms have 5 or more words between them) • Additionally, the same document must contain the word 'python' in the body field, but not contain either 'php' or 'perl'; • Additionally, the same document must contain the word 'code' in any field. There always is implicit AND operator, so 'hello world' means that both 'hello' and 'world' must be present in matching document. OR operator precedence is higher than AND, so 'looking for cat dog mouse' means 'looking for ( cat dog mouse )' and not '(looking for cat) dog mouse'. Field limit operator limits subsequent searching to a given field.

Normally, query will fail with an error message if given field name does not exist in the searched index. However, that can be suppressed by specifying '@@relaxed' option at the very beginning of the query: @@relaxed @nosuchfield my query This can be helpful when searching through heterogeneous indexes with different schemas. Field position limit, introduced in version 0.9.9-rc1, additionally restricts the searching to first N position within given field (or fields). For example, '@body[50] hello' will not match the documents where the keyword 'hello' occurs at position 51 and below in the body. Proximity distance is specified in words, adjusted for word count, and applies to all words within quotes.

For instance, 'cat dog mouse'~5 query means that there must be less than 8-word span which contains all 3 words, ie. 'CAT aaa bbb ccc DOG eee fff MOUSE' document will not match this query, because this span is exactly 8 words long. Quorum matching operator introduces a kind of fuzzy matching. It will only match those documents that pass a given threshold of given words.

The example above ('the world is a wonderful place'/3) will match all documents that have at least 3 of the 6 specified words. Operator is limited to 255 keywords. Instead of an absolute number, you can also specify a number between 0.0 and 1.0 (standing for 0% and 100%), and Sphinx will match only documents with at least the specified percentage of given words.

The same example above could also have been written 'the world is a wonderful place'/0.5 and it would match documents with at least 50% of the 6 words. Strict order operator (aka operator 'before'), introduced in version 0.9.9-rc2, will match the document only if its argument keywords occur in the document exactly in the query order.

For instance, 'black Table 1. Local awareness of Hello Kitty brand.. Some table data goes here. World-wide brand awareness. ZONE operator affects the query until the next field or ZONE limit operator, or the closing parenthesis.

It only works on the indexes built with zones support (see ) and will be ignored otherwise. ZONESPAN limit operator, added in 2.1.1-beta, is similar to the ZONE operator, but requires the match to occur in a single contiguous span. In the example above, (ZONESPAN:th hello world)>would not match the document, since 'hello' and 'world' do not occur within the same span.

MAYBE operator was added in 2.2.3-beta. It works much like operator but doesn't return documents which match only right subtree expression. 5.4.1. Ranking overview Ranking (aka weighting) of the search results can be defined as a process of computing a so-called relevance (aka weight) for every given matched document with regards to a given query that matched it.

So relevance is in the end just a number attached to every document that estimates how relevant the document is to the query. Search results can then be sorted based on this number and/or some additional parameters, so that the most sought after results would come up higher on the results page. There is no single standard one-size-fits-all way to rank any document in any scenario. Moreover, there can not ever be such a way, because relevance is subjective. As in, what seems relevant to you might not seem relevant to me. Hence, in general case it's not just hard to compute, it's theoretically impossible. So ranking in Sphinx is configurable.

It has a notion of a so-called ranker. A ranker can formally be defined as a function that takes document and query as its input and produces a relevance value as output. In layman's terms, a ranker controls exactly how (using which specific algorithm) will Sphinx assign weights to the document. Previously, this ranking function was rigidly bound to the matching mode.

So in the legacy matching modes (that is, SPH_MATCH_ALL, SPH_MATCH_ANY, SPH_MATCH_PHRASE, and SPH_MATCH_BOOLEAN) you can not choose the ranker. You can only do that in the SPH_MATCH_EXTENDED mode. (Which is the only mode in SphinxQL and the suggested mode in SphinxAPI anyway.) To choose a non-default ranker you can either use with SphinxAPI, or clause in SELECT statement when using SphinxQL. As a sidenote, legacy matching modes are internally implemented via the unified syntax anyway.

When you use one of those modes, Sphinx just internally adjusts the query and sets the associated ranker, then executes the query using the very same unified code path. 5.4.2. Available built-in rankers Sphinx ships with a number of built-in rankers suited for different purposes. A number of them uses two factors, phrase proximity (aka LCS) and BM25. Phrase proximity works on the keyword positions, while BM25 works on the keyword frequencies.

Basically, the better the degree of the phrase match between the document body and the query, the higher is the phrase proximity (it maxes out when the document contains the entire query as a verbatim quote). And BM25 is higher when the document contains more rare words. We'll save the detailed discussion for later. Currently implemented rankers are. • SPH_RANK_PROXIMITY_BM25, the default ranking mode that uses and combines both phrase proximity and BM25 ranking. • SPH_RANK_BM25, statistical ranking mode which uses BM25 ranking only (similar to most other full-text engines).

This mode is faster but may result in worse quality on queries which contain more than 1 keyword. • SPH_RANK_NONE, no ranking mode.

This mode is obviously the fastest. A weight of 1 is assigned to all matches. This is sometimes called boolean searching that just matches the documents but does not rank them. • SPH_RANK_WORDCOUNT, ranking by the keyword occurrences count. This ranker computes the per-field keyword occurrence counts, then multiplies them by field weights, and sums the resulting values. • SPH_RANK_PROXIMITY, added in version 0.9.9-rc1, returns raw phrase proximity value as a result.

This mode is internally used to emulate SPH_MATCH_ALL queries. • SPH_RANK_MATCHANY, added in version 0.9.9-rc1, returns rank as it was computed in SPH_MATCH_ANY mode earlier, and is internally used to emulate SPH_MATCH_ANY queries. • SPH_RANK_FIELDMASK, added in version 0.9.9-rc2, returns a 32-bit mask with N-th bit corresponding to N-th fulltext field, numbering from 0. The bit will only be set when the respective field has any keyword occurrences satisfying the query. • SPH_RANK_SPH04, added in version 1.10-beta, is generally based on the default SPH_RANK_PROXIMITY_BM25 ranker, but additionally boosts the matches when they occur in the very beginning or the very end of a text field. Thus, if a field equals the exact query, SPH04 should rank it higher than a field that contains the exact query but is not equal to it. (For instance, when the query is 'Hyde Park', a document entitled 'Hyde Park' should be ranked higher than a one entitled 'Hyde Park, London' or 'The Hyde Park Cafe'.) • SPH_RANK_EXPR, added in version 2.0.2-beta, lets you specify the ranking formula in run time.

It exposes a number of internal text factors and lets you define how the final weight should be computed from those factors. You can find more details about its syntax and a reference available factors in a subsection below. You should specify the SPH_RANK_ prefix and use capital letters only when using the call from the SphinxAPI. The API ports expose these as global constants. Using SphinxQL syntax, the prefix should be omitted and the ranker name is case insensitive. Example: // SphinxAPI $client->SetRankingMode ( SPH_RANK_SPH04 ); // SphinxQL mysql_query ( 'SELECT.

OPTION ranker=sph04' ); Legacy matching modes rankers Legacy matching modes automatically select a ranker as follows. 5.4.3. Expression based ranker (SPH_RANK_EXPR) Expression ranker, added in version 2.0.2-beta, lets you change the ranking formula on the fly, on a per-query basis.

For a quick kickoff, this is how you emulate PROXIMITY_BM25 ranker using the expression based one: SELECT *, WEIGHT() FROM myindex WHERE MATCH('hello world') OPTION ranker=expr('sum(lcs*user_weight)*1000+bm25') The output of this query must not change if you omit the OPTION clause, because the default ranker (PROXIMITY_BM25) behaves exactly like specified in the ranker formula above. But the expression ranker is somewhat more flexible than just that and provides access to many more factors. The ranking formula is an arbitrary arithmetic expression that can use constants, document attributes, built-in functions and operators (described in ), and also a few ranking-specific things that are only accessible in a ranking formula. Namely, those are field aggregation functions, field-level, and document-level ranking factors. • bm25 (integer), a document-level BM25 estimate (computed without keyword occurrence filtering).

• max_lcs (integer), a query-level maximum possible value that the sum(lcs*user_weight) expression can ever take. This can be useful for weight boost scaling. For instance, MATCHANY ranker formula uses this to guarantee that a full phrase match in any field ranks higher than any combination of partial matches in all fields.

• field_mask (integer), a document-level 32-bit mask of matched fields. • query_word_count (integer), the number of unique keywords in a query, adjusted for a number of excluded keywords. For instance, both (one one one one) and (one!two) queries should assign a value of 1 to this factor, because there is just one unique non-excluded keyword. • doc_word_count (integer), the number of unique keywords matched in the entire document. 5.4.6. Field-level ranking factors A field-level factor is a numeric value computed by the ranking engine for every matched in-document text field with regards to the current query.

As more than one field can be matched by a query, but the final weight needs to be a single integer value, these values need to be folded into a single one. To achieve that, field-level factors can only be used within a field aggregation function, they can not be used anywhere in the expression. For example, you can not use (lcs+bm25) as your ranking expression, as lcs takes multiple values (one in every matched field). You should use (sum(lcs)+bm25) instead, that expression sums lcs over all matching fields, and then adds bm25 to that per-field sum. Currently implemented field-level factors are.

• lcs (integer), the length of a maximum verbatim match between the document and the query, counted in words. LCS stands for Longest Common Subsequence (or Subset).

Takes a minimum value of 1 when only stray keywords were matched in a field, and a maximum value of query keywords count when the entire query was matched in a field verbatim (in the exact query keywords order). For example, if the query is 'hello world' and the field contains these two words quoted from the query (that is, adjacent to each other, and exactly in the query order), lcs will be 2. For example, if the query is 'hello world program' and the field contains 'hello world', lcs will be 2. Note that any subset of the query keyword works, not just a subset of adjacent keywords. For example, if the query is 'hello world program' and the field contains 'hello (test program)', lcs will be 2 just as well, because both 'hello' and 'program' matched in the same respective positions as they were in the query. Finally, if the query is 'hello world program' and the field contains 'hello world program', lcs will be 3.

(Hopefully that is unsurprising at this point.) • user_weight (integer), the user specified per-field weight (refer to in SphinxAPI and in SphinxQL respectively). The weights default to 1 if not specified explicitly. • hit_count (integer), the number of keyword occurrences that matched in the field.

Note that a single keyword may occur multiple times. For example, if 'hello' occurs 3 times in a field and 'world' occurs 5 times, hit_count will be 8. • word_count (integer), the number of unique keywords matched in the field. For example, if 'hello' and 'world' occur anywhere in a field, word_count will be 2, irregardless of how many times do both keywords occur.

• tf_idf (float), the sum of TF*IDF over all the keywords matched in the field. IDF is the Inverse Document Frequency, a floating point value between 0 and 1 that describes how frequent is the keywords (basically, 0 for a keyword that occurs in every document indexed, and 1 for a unique keyword that occurs in just a single document). TF is the Term Frequency, the number of matched keyword occurrences in the field. As a side note, tf_idf is actually computed by summing IDF over all matched occurrences. That's by construction equivalent to summing TF*IDF over all matched keywords. • min_hit_pos (integer), the position of the first matched keyword occurrence, counted in words.

Indexing begins from position 1. • min_best_span_pos (integer), the position of the first maximum LCS occurrences span. For example, assume that our query was 'hello world program' and 'hello world' subphrase was matched twice in the field, in positions 13 and 21.

Assume that 'hello' and 'world' additionally occurred elsewhere in the field, but never next to each other and thus never as a subphrase match. In that case, min_best_span_pos will be 13. Note how for the single keyword queries min_best_span_pos will always equal min_hit_pos. • exact_hit (boolean), whether a query was an exact match of the entire current field. Used in the SPH04 ranker. • min_idf, max_idf, and sum_idf (float), added in version 2.1.1-beta. These factors respectively represent the min(idf), max(idf) and sum(idf) over all keywords that were matched in the field.

• exact_order (boolean), added in version 2.2.1-beta. Whether all of the query keywords were matched in the field in the exact query order.

For example, (microsoft office) query would yield exact_order=1 in a field with the following contents: (We use Microsoft software in our office.). However, the very same query in a (Our office is Microsoft free.) field would yield exact_order=0. • min_gaps (integer), added in version 2.2.1-beta, the minimum number of positional gaps between (just) the keywords matched in field. Always 0 when less than 2 keywords match; always greater or equal than 0 otherwise. For example, with a [big wolf] query, [big bad wolf] field would yield min_gaps=1; [big bad hairy wolf] field would yield min_gaps=2; [the wolf was scary and big] field would yield min_gaps=3; etc.

However, a field like [i heard a wolf howl] would yield min_gaps=0, because only one keyword would be matching in that field, and, naturally, there would be no gaps between the matchedkeywords. Therefore, this is a rather low-level, 'raw' factor that you would most likely want to adjust before actually using for ranking. Specific adjustments depend heavily on your data and the resulting formula, but here are a few ideas you can start with: (a) any min_gaps based boosts could be simply ignored when word_count=2) could be clamped with a certain 'worst case' constant while trivial values (i.e.

When min_gaps=0 and word_count. Arithmetic operators: +, -, *, /,%, DIV, MOD The standard arithmetic operators. Arithmetic calculations involving those can be performed in three different modes: (a) using single-precision, 32-bit IEEE 754 floating point values (the default), (b) using signed 32-bit integers, (c) using 64-bit signed integers. The expression parser will automatically switch to integer mode if there are no operations the result in a floating point value. Otherwise, it will use the default floating point mode. For instance, a+b will be computed using 32-bit integers if both arguments are 32-bit integers; or using 64-bit integers if both arguments are integers but one of them is 64-bit; or in floats otherwise.

However, a/b or sqrt(a) will always be computed in floats, because these operations return a result of non-integer type. To avoid the first, you can either use IDIV(a,b) or a DIV b form. Also, a*b will not be automatically promoted to 64-bit when the arguments are 32-bit.

To enforce 64-bit results, you can use BIGINT(). (But note that if there are non-integer operations, BIGINT() will simply be ignored.) Comparison operators: =, =, Comparison operators (eg. = or operators) introduce a small equality threshold (1e-6 by default).

If the difference between compared values is within the threshold, they will be considered equal. Boolean operators: AND, OR, NOT Boolean operators (AND, OR, NOT) were introduced in 0.9.9-rc2 and behave as usual. They are left-associative and have the least priority compared to other operators. NOT has more priority than AND and OR but nevertheless less than any other operator. AND and OR have the same priority so brackets use is recommended to avoid confusion in complex expressions. Bitwise operators: &, These operators perform bitwise AND and OR respectively. The operands must be of an integer types.

Introduced in version 1.10-beta. ABS() Returns the absolute value of the argument. BITDOT() BITDOT(mask, w0, w1.) returns the sum of products of an each bit of a mask multiplied with its weight. Bit0*w0 + bit1*w1 +.

CEIL() Returns the smallest integer value greater or equal to the argument. CONTAINS() CONTAINS(polygon, x, y) checks whether the (x,y) point is within the given polygon, and returns 1 if true, or 0 if false. The polygon has to be specified using either the function or the function. The former function is intended for 'small' polygons, meaning less than 500 km (300 miles) a side, and it doesn't take into account the Earth's curvature for speed.

For larger distances, you should use GEOPOLY2D, which tessellates the given polygon in smaller parts, accounting for the Earth's curvature. These functions were added in version 2.1.1-beta.

COS() Returns the cosine of the argument. DOUBLE() Forcibly promotes given argument to floating point type. Intended to help enforce evaluation of numeric JSON fields. Introduced in version 2.2.1-beta. EXP() Returns the exponent of the argument (e=2.718. To the power of the argument).

FIBONACCI() Returns the N-th Fibonacci number, where N is the integer argument. That is, arguments of 0 and up will generate the values 0, 1, 1, 2, 3, 5, 8, 13 and so on. Note that the computations are done using 32-bit integer math and thus numbers 48th and up will be returned modulo 2^32. FLOOR() Returns the largest integer value lesser or equal to the argument. GEOPOLY2D() GEOPOLY2D(x1,y1,x2,y2,x3,y3.) produces a polygon to be used with the function. This function takes into account the Earth's curvature by tessellating the polygon into smaller ones, and should be used for larger areas; see the function. The function expects coordinates to be in degrees, if radians are used it will give same result as POLY2D().

IDIV() Returns the result of an integer division of the first argument by the second argument. Both arguments must be of an integer type. LN() Returns the natural logarithm of the argument (with the base of e=2.718.). LOG10() Returns the common logarithm of the argument (with the base of 10). LOG2() Returns the binary logarithm of the argument (with the base of 2). MAX() Returns the bigger of two arguments. MIN() Returns the smaller of two arguments.

POLY2D() POLY2D(x1,y1,x2,y2,x3,y3.) produces a polygon to be used with the function. This polygon assumes a flat Earth, so it should not be too large; see the function.

POW() Returns the first argument raised to the power of the second argument. SIN() Returns the sine of the argument. SQRT() Returns the square root of the argument. UINT() Forcibly reinterprets given argument to 64-bit unsigned type. Introduced in version 2.2.1-beta. DAY() Returns the integer day of month (in 1.31 range) from a timestamp argument, according to the current timezone.

Introduced in version 2.0.1-beta. MONTH() Returns the integer month (in 1.12 range) from a timestamp argument, according to the current timezone. Introduced in version 2.0.1-beta. NOW() Returns the current timestamp as an INTEGER. Introduced in version 0.9.9-rc1.

YEAR() Returns the integer year (in 1969.2038 range) from a timestamp argument, according to the current timezone. Introduced in version 2.0.1-beta. YEARMONTH() Returns the integer year and month code (in 101 range) from a timestamp argument, according to the current timezone. Introduced in version 2.0.1-beta. YEARMONTHDAY() Returns the integer year, month, and date code (in 1960119 range) from a timestamp argument, according to the current timezone. Introduced in version 2.0.1-beta. BIGINT() Forcibly promotes the integer argument to 64-bit type, and does nothing on floating point argument.

It's intended to help enforce evaluation of certain expressions (such as a*b) in 64-bit mode even though all the arguments are 32-bit. Introduced in version 0.9.9-rc1. INTEGER() Forcibly promotes given argument to 64-bit signed type. Intended to help enforce evaluation of numeric JSON fields.

Introduced in version 2.2.1-beta. SINT() Forcibly reinterprets its 32-bit unsigned integer argument as signed, and also expands it to 64-bit type (because 32-bit type is unsigned). It's easily illustrated by the following example: 1-2 normally evaluates to, but SINT(1-2) evaluates to -1.

Introduced in version 1.10-beta. IF() IF() behavior is slightly different that that of its MySQL counterpart.

It takes 3 arguments, check whether the 1st argument is equal to 0.0, returns the 2nd argument if it is not zero, or the 3rd one when it is. Note that unlike comparison operators, IF() does not use a threshold! Therefore, it's safe to use comparison results as its 1st argument, but arithmetic operators might produce unexpected results.

For instance, the following two calls will produce different results even though they are logically equivalent: IF ( sqrt(3)*sqrt(3)-30, a, b ) IF ( sqrt(3)*sqrt(3)-3, a, b ) In the first case, the comparison operator will return 0.0 (false) because of a threshold, and IF() will always return 'b' as a result. In the second one, the same sqrt(3)*sqrt(3)-3 expression will be compared with zero without threshold by the IF() function itself. But its value will be slightly different from zero because of limited floating point calculations precision. Because of that, the comparison with 0.0 done by IF() will not pass, and the second variant will return 'a' as a result. IN() IN(expr,val1,val2.), introduced in version 0.9.9-rc1, takes 2 or more arguments, and returns 1 if 1st argument (expr) is equal to any of the other arguments (val1.valN), or 0 otherwise. Currently, all the checked values (but not the expression itself!) are required to be constant. (Its technically possible to implement arbitrary expressions too, and that might be implemented in the future.) Constants are pre-sorted and then binary search is used, so IN() even against a big arbitrary list of constants will be very quick.

Starting with 0.9.9-rc2, first argument can also be a MVA attribute. In that case, IN() will return 1 if any of the MVA values is equal to any of the other arguments. Starting with 2.0.1-beta, IN() also supports IN(expr,@uservar) syntax to check whether the value belongs to the list in the given global user variable.

First argument can be JSON attribute since 2.2.1-beta. INTERVAL() INTERVAL(expr,point1,point2,point3.), introduced in version 0.9.9-rc1, takes 2 or more arguments, and returns the index of the argument that is less than the first argument: it returns 0 if expr.

• last hour, • last day, • last week, • last month, • last 3 months, • everything else. These segments are hardcoded, but it is trivial to change them if necessary. This mode was added to support searching through blogs, news headlines, etc.

When using time segments, recent records would be ranked higher because of segment, but within the same segment, more relevant records would be ranked higher - unlike sorting by just the timestamp attribute, which would not take relevance into account at all. SPH_SORT_EXTENDED mode In SPH_SORT_EXTENDED mode, you can specify an SQL-like sort expression with up to 5 attributes (including internal attributes), eg: @relevance DESC, price ASC, @id DESC Both internal attributes (that are computed by the engine on the fly) and user attributes that were configured for this index are allowed. Internal attribute names must start with magic @-symbol; user attribute names can be used as is. In the example above, @relevance and @id are internal attributes and price is user-specified. Known internal attributes are. • @id (match ID) • @weight (match weight) • @rank (match weight) • @relevance (match weight) • @random (return results in random order) @rank and @relevance are just additional aliases to @weight.

SPH_SORT_EXPR mode Expression sorting mode lets you sort the matches by an arbitrary arithmetic expression, involving attribute values, internal attributes (@id and @weight), arithmetic operations, and a number of built-in functions. Here's an example: $cl->SetSortMode ( SPH_SORT_EXPR, '@weight + ( user_karma + ln(pageviews) )*0.1' ); The operators and functions supported in the expressions are discussed in a separate section,. 5.7. Grouping (clustering) search results Sometimes it could be useful to group (or in other terms, cluster) search results and/or count per-group match counts - for instance, to draw a nice graph of how much matching blog posts were there per each month; or to group Web search results by site; or to group matching forum posts by author; etc.

In theory, this could be performed by doing only the full-text search in Sphinx and then using found IDs to group on SQL server side. However, in practice doing this with a big result set (10K-10M matches) would typically kill performance. To avoid that, Sphinx offers so-called grouping mode. It is enabled with SetGroupBy() API call. When grouping, all matches are assigned to different groups based on group-by value. This value is computed from specified attribute using one of the following built-in functions. • SPH_GROUPBY_DAY, extracts year, month and day in YYYYMMDD format from timestamp; • SPH_GROUPBY_WEEK, extracts year and first day of the week number (counting from year start) in YYYYNNN format from timestamp; • SPH_GROUPBY_MONTH, extracts month in YYYYMM format from timestamp; • SPH_GROUPBY_YEAR, extracts year in YYYY format from timestamp; • SPH_GROUPBY_ATTR, uses attribute value itself for grouping.

The final search result set then contains one best match per group. Grouping function value and per-group match count are returned along as 'virtual' attributes named @group and @count respectively. The result set is sorted by group-by sorting clause, with the syntax similar to syntax.

In addition to @id and @weight, group-by sorting clause may also include. • @group (groupby function value), • @count (amount of matches in group). The default mode is to sort by groupby value in descending order, ie. By '@group desc'. On completion, total_found result parameter would contain total amount of matching groups over he whole index. WARNING: grouping is done in fixed memory and thus its results are only approximate; so there might be more groups reported in total_found than actually present. @count might also be underestimated.

To reduce inaccuracy, one should raise max_matches. If max_matches allows to store all found groups, results will be 100% correct. For example, if sorting by relevance and grouping by 'published' attribute with SPH_GROUPBY_DAY function, then the result set will contain. 5.8. Distributed searching To scale well, Sphinx has distributed searching capabilities.

Distributed searching is useful to improve query latency (ie. Search time) and throughput (ie. Max queries/sec) in multi-server, multi-CPU or multi-core environments. This is essential for applications which need to search through huge amounts data (ie.

Billions of records and terabytes of text). The key idea is to horizontally partition (HP) searched data across search nodes and then process it in parallel. Partitioning is done manually.

• setup several instances of Sphinx programs ( indexer and searchd) on different servers; • make the instances index (and search) different parts of data; • configure a special distributed index on some of the searchd instances; • and query this index. This index only contains references to other local and remote indexes - so it could not be directly reindexed, and you should reindex those indexes which it references instead. When searchd receives a query against distributed index, it does the following.

• connects to configured remote agents; • issues the query; • sequentially searches configured local indexes (while the remote agents are searching); • retrieves remote agents' search results; • merges all the results together, removing the duplicates; • sends the merged results to client. From the application's point of view, there are no differences between searching through a regular index, or a distributed index at all. That is, distributed indexes are fully transparent to the application, and actually there's no way to tell whether the index you queried was distributed or local. (Even though as of 0.9.9 Sphinx does not allow to combine searching through distributed indexes with anything else, this constraint will be lifted in the future.) Any searchd instance could serve both as a master (which aggregates the results) and a slave (which only does local searching) at the same time.

This has a number of uses. • every machine in a cluster could serve as a master which searches the whole cluster, and search requests could be balanced between masters to achieve a kind of HA (high availability) in case any of the nodes fails; • if running within a single multi-CPU or multi-core machine, there would be only 1 searchd instance querying itself as an agent and thus utilizing all CPUs/core.

It is scheduled to implement better HA support which would allow to specify which agents mirror each other, do health checks, keep track of alive agents, load-balance requests, etc. Searchd query log formats In version 2.0.1-beta and above two query log formats are supported. Previous versions only supported a custom plain text format. That format is still the default one. However, while it might be more convenient for manual monitoring and review, but hard to replay for benchmarks, it only logs search queries but not the other types of requests, does not always contain the complete search query data, etc. The default text format is also harder (and sometimes impossible) to replay for benchmarking purposes.

The new sphinxql format alleviates that. It aims to be complete and automatable, even though at the cost of brevity and readability.

• 'rel' for SPH_SORT_RELEVANCE mode; • 'attr-' for SPH_SORT_ATTR_DESC mode; • 'attr+' for SPH_SORT_ATTR_ASC mode; • 'tsegs' for SPH_SORT_TIME_SEGMENTS mode; • 'ext' for SPH_SORT_EXTENDED mode. Additionally, if searchd was started with --iostats, there will be a block of data after where the index(es) searched are listed. A query log entry might take the form of: [Fri Jun 29 21:] 0.004 sec [all/0/rel 35254 (0,20)] [lj] [ios=6 kb=111.1 ms=0.5] test This additional block is information regarding I/O operations in performing the search: the number of file I/O operations carried out, the amount of data in kilobytes read from the index files and time spent on I/O operations (although there is a background processing component, the bulk of this time is the I/O operation time). 5.9.2. SphinxQL log format This is a new log format introduced in 2.0.1-beta, with the goals begin logging everything and then some, and in a format easy to automate (for instance, automatically replay). New format can either be enabled via the directive in the configuration file, or switched back and forth on the fly with the statement via SphinxQL.

In the new format, the example from the previous section would look as follows. (Wrapped below for readability, but with just one query per line in the actual log.) /* Fri Jun 29 21:17:58.609 2007 2011 conn 2 real 0.004 wall 0.004 found 35254 */ SELECT * FROM lj WHERE MATCH('test') OPTION ranker=proximity; /* Fri Jun 29 21.555 conn 3 real 0.024 wall 0.024 found 19886 */ SELECT * FROM lj WHERE MATCH('test') GROUP BY channel_id OPTION ranker=proximity; Note that all requests would be logged in this format, including those sent via SphinxAPI and SphinxSE, not just those sent via SphinxQL. Also note, that this kind of logging works only with plain log files and will not work if you use 'syslog' for logging.

The features of SphinxQL log format compared to the default text one are as follows. • All request types should be logged. (This is still work in progress.) • Full statement data will be logged where possible. • Errors and warnings are logged.

• The log should be automatically replayable via SphinxQL. • Additional performance counters (currently, per-agent distributed query times) are logged. Use sphinxql:compact_in to shorten your IN() clauses in log if you have too much values in it. Every request (including both SphinxAPI and SphinxQL) request must result in exactly one log line.

All request types, including INSERT, CALL SNIPPETS, etc will eventually get logged, though as of time of this writing, that is a work in progress). Every log line must be a valid SphinxQL statement that reconstructs the full request, except if the logged request is too big and needs shortening for performance reasons. Additional messages, counters, etc can be logged in the comments section after the request. 5.10. MySQL protocol support and SphinxQL Starting with version 0.9.9-rc2, Sphinx searchd daemon supports MySQL binary network protocol and can be accessed with regular MySQL API. For instance, 'mysql' CLI client program works well. Here's an example of querying Sphinx using MySQL client: $ mysql -P 9306 Welcome to the MySQL monitor.

Commands end with; or g. Your MySQL connection id is 1 Server version: 0.9.9-dev (r1734) Type 'help;' or ' h' for help. Type ' c' to clear the buffer.

Mysql>SELECT * FROM test1 WHERE MATCH('test') ->ORDER BY group_id ASC OPTION ranker=bm25; +------+--------+----------+------------+ id weight group_id date_added +------+--------+----------+------------+ 4 1442 2 2 2421 123 1 2421 456 +------+--------+----------+------------+ 3 rows in set (0.00 sec) Note that mysqld was not even running on the test machine. Everything was handled by searchd itself. The new access method is supported in addition to native APIs which all still work perfectly well. In fact, both access methods can be used at the same time. Also, native API is still the default access method. MySQL protocol support needs to be additionally configured.

This is a matter of 1-line config change, adding a new with mysql41 specified as a protocol: listen = localhost:9306:mysql41 Just supporting the protocol and not the SQL syntax would be useless so Sphinx now also supports a subset of SQL that we dubbed SphinxQL. It supports the standard querying all the index types with SELECT, modifying RT indexes with INSERT, REPLACE, and DELETE, and much more. Full SphinxQL reference is available in.

5.11. Multi-queries Multi-queries, or query batches, let you send multiple queries to Sphinx in one go (more formally, one network request). Two API methods that implement multi-query mechanism are and. You can also run multiple queries with SphinxQL, see. (In fact, regular call is internally implemented as a single AddQuery() call immediately followed by RunQueries() call.) AddQuery() captures the current state of all the query settings set by previous API calls, and memorizes the query. RunQueries() actually sends all the memorized queries, and returns multiple result sets.

There are no restrictions on the queries at all, except just a sanity check on a number of queries in a single batch (see ). Why use multi-queries? Generally, it all boils down to performance. First, by sending requests to searchd in a batch instead of one by one, you always save a bit by doing less network roundtrips. Second, and somewhat more important, sending queries in a batch enables searchd to perform certain internal optimizations. As new types of optimizations are being added over time, it generally makes sense to pack all the queries into batches where possible, so that simply upgrading Sphinx to a new version would automatically enable new optimizations. In the case when there aren't any possible batch optimizations to apply, queries will be processed one by one internally.

Why (or rather when) not use multi-queries? Multi-queries requires all the queries in a batch to be independent, and sometimes they aren't. That is, sometimes query B is based on query A results, and so can only be set up after executing query A. For instance, you might want to display results from a secondary index if and only if there were no results found in a primary index. Or maybe just specify offset into 2nd result set based on the amount of matches in the 1st result set.

In that case, you will have to use separate queries (or separate batches). As of 0.9.10, there are two major optimizations to be aware of: common query optimization (available since 0.9.8); and common subtree optimization (available since 0.9.10). Common query optimization means that searchd will identify all those queries in a batch where only the sorting and group-by settings differ, and only perform searching once. For instance, if a batch consists of 3 queries, all of them are for 'ipod nano', but 1st query requests top-10 results sorted by price, 2nd query groups by vendor ID and requests top-5 vendors sorted by rating, and 3rd query requests max price, full-text search for 'ipod nano' will only be performed once, and its results will be reused to build 3 different result sets. So-called faceted searching is a particularly important case that benefits from this optimization. Indeed, faceted searching can be implemented by running a number of queries, one to retrieve search results themselves, and a few other ones with same full-text query but different group-by settings to retrieve all the required groups of results (top-3 authors, top-5 vendors, etc). And as long as full-text query and filtering settings stay the same, common query optimization will trigger, and greatly improve performance.

Common subtree optimization is even more interesting. It lets searchd exploit similarities between batched full-text queries. It identifies common full-text query parts (subtrees) in all queries, and caches them between queries. For instance, look at the following query batch: barack obama president barack obama john mccain barack obama speech There's a common two-word part ('barack obama') that can be computed only once, then cached and shared across the queries. And common subtree optimization does just that. Per-query cache size is strictly controlled by and directives (so that caching all sixteen gazillions of documents that match 'i am' does not exhaust the RAM and instantly kill your server). Here's a code sample (in PHP) that fire the same query in 3 different sorting modes: require ( 'sphinxapi.php' ); $cl = new SphinxClient (); $cl->SetMatchMode ( SPH_MATCH_EXTENDED ); $cl->SetSortMode ( SPH_SORT_RELEVANCE ); $cl->AddQuery ( 'the', 'lj' ); $cl->SetSortMode ( SPH_SORT_EXTENDED, 'published desc' ); $cl->AddQuery ( 'the', 'lj' ); $cl->SetSortMode ( SPH_SORT_EXTENDED, 'published asc' ); $cl->AddQuery ( 'the', 'lj' ); $res = $cl->RunQueries(); How to tell whether the queries in the batch were actually optimized?

If they were, respective query log will have a 'multiplier' field that specifies how many queries were processed together: [Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/rel 747541 (0,20)] [lj] the [Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/ext 747541 (0,20)] [lj] the [Sun Jul 12 15:18:17.000 2009] 0.040 sec x3 [ext/0/ext 747541 (0,20)] [lj] the Note the 'x3' field. It means that this query was optimized and processed in a sub-batch of 3 queries. For reference, this is how the regular log would look like if the queries were not batched: [Sun Jul 12 15:18:17.062 2009] 0.059 sec [ext/0/rel 747541 (0,20)] [lj] the [Sun Jul 12 15:18:17.156 2009] 0.091 sec [ext/0/ext 747541 (0,20)] [lj] the [Sun Jul 12 15:18:17.250 2009] 0.092 sec [ext/0/ext 747541 (0,20)] [lj] the Note how per-query time in multi-query case was improved by a factor of 1.5x to 2.3x, depending on a particular sorting mode.

In fact, for both common query and common subtree optimizations, there were reports of 3x and even more improvements, and that's from production instances, not just synthetic tests. • libc_ci • libc_cs • utf8_general_ci • binary The first two collations rely on several standard C library (libc) calls and can thus support any locale that is installed on your system. They provide case-insensitive (_ci) and case-sensitive (_cs) comparisons respectively. By default they will use C locale, effectively resorting to bytewise comparisons. To change that, you need to specify a different available locale using directive.

The list of locales available on your system can usually be obtained with the locale command: $ locale -a C en_AG en_AU.utf8 en_BW.utf8 en_CA.utf8 en_DK.utf8 en_GB.utf8 en_HK.utf8 en_IE.utf8 en_IN en_NG en_NZ.utf8 en_PH.utf8 en_SG.utf8 en_US.utf8 en_ZA.utf8 en_ZW.utf8 es_ES fr_FR POSIX ru_RU.utf8 ru_UA.utf8 The specific list of the system locales may vary. Consult your OS documentation to install additional needed locales.

Utf8_general_ci and binary locales are built-in into Sphinx. The first one is a generic collation for UTF-8 data (without any so-called language tailoring); it should behave similar to utf8_general_ci collation in MySQL.

The second one is a simple bytewise comparison. Collation can be overridden via SphinxQL on a per-session basis using SET collation_connection statement. All subsequent SphinxQL queries will use this collation. SphinxAPI and SphinxSE queries will use the server default collation, as specified in configuration directive. Sphinx currently defaults to libc_ci collation. Collations should affect all string attribute comparisons, including those within ORDER BY and GROUP BY, so differently ordered or grouped results can be returned depending on the collation chosen.

Note that collations don't affect full-text searching, for that use. • UDFs referenced in WHERE, ORDER BY, or GROUP BY clauses must and will be evaluated for every matched document. They will be called in the natural matching order. • without subselects, UDFs that can be evaluated at the very last stage over the final result set will be evaluated that way, but before applying the LIMIT clause.

They will be called in the result set order. • with subselects, such UDFs will also be evaluated after applying the inner LIMIT clause.

The calling sequence of the other functions is fixed, though. • testfunc_init() is called once when initializing the query. It can return a non-zero code to indicate a failure; in that case query will be terminated, and the error message from the error_message buffer will be returned. • testfunc() is called for every eligible row (see above), whenever Sphinx needs to compute the UDF value. It can also indicate an (internal) failure error by writing a non-zero byte value to error_flag. In that case, it is guaranteed that will no more be called for subsequent rows, and a default return value of 0 will be substituted. Sphinx might or might not choose to terminate such queries early, neither behavior is currently guaranteed.

• testfunc_deinit() is called once when the query processing (in a given index shard) ends. As of 2.2.2-beta, we do not yet support aggregation functions.

In other words, your UDFs will be called for just a single document at a time and are expected to return some value for that document. Writing a function that can compute an aggregate value like AVG() over the entire group of documents that share the same GROUP BY key is not yet possible. However, you can use UDFs within the builtin aggregate functions: that is, even though MYCUSTOMAVG() is not supported yet, AVG(MYCUSTOMFUNC()) should work alright!

UDFs are local. In order to use them on a cluster, you have to put the same library on all its nodes and run CREATEs on all the nodes too. This might change in the future versions. • XXX_init() gets called once per query per index, in the very beginning. A few query-wide options are passed to it through a SPH_RANKER_INIT structure, including the user options strings (in the example just above, 'option1=1' is that string). • XXX_update() gets called multiple times per matched document, with every matched keyword occurrence passed as its parameter, a SPH_RANKER_HIT structure.

The occurrences within each document are guaranteed to be passed in the order of ascending hit->hit_pos values. • XXX_finalize() gets called once per matched document, once there are no more keyword occurrences. It must return the WEIGHT() value. This is the only mandatory function. • XXX_deinit() gets called once per query, in the very end.

Indexer command reference indexer is the first of the two principal tools as part of Sphinx. Invoked from either the command line directly, or as part of a larger script, indexer is solely responsible for gathering the data that will be searchable.

The calling syntax for indexer is as follows: indexer [OPTIONS] [indexname1 [indexname2 [.]]] Essentially you would list the different possible indexes (that you would later make available to search) in sphinx.conf, so when calling indexer, as a minimum you need to be telling it what index (or indexes) you want to index. If sphinx.conf contained details on 2 indexes, mybigindex and mysmallindex, you could do the following: $ indexer mybigindex $ indexer mysmallindex mybigindex As part of the configuration file, sphinx.conf, you specify one or more indexes for your data. You might call indexer to reindex one of them, ad-hoc, or you can tell it to process all indexes - you are not limited to calling just one, or all at once, you can always pick some combination of the available indexes. The exit codes are as follows. • --config ( -c for short) tells indexer to use the given file as its configuration. Normally, it will look for sphinx.conf in the installation directory (e.g.

/usr/local/sphinx/etc/sphinx.conf if installed into /usr/local/sphinx), followed by the current directory you are in when calling indexer from the shell. This is most of use in shared environments where the binary files are installed somewhere like /usr/local/sphinx/ but you want to provide users with the ability to make their own custom Sphinx set-ups, or if you want to run multiple instances on a single server. In cases like those you could allow them to create their own sphinx.conf files and pass them to indexer with this option. For example: $ indexer --config /home/myuser/sphinx.conf myindex • --all tells indexer to update every index listed in sphinx.conf, instead of listing individual indexes.

This would be useful in small configurations, or cron-type or maintenance jobs where the entire index set will get rebuilt each day, or week, or whatever period is best. Example usage: $ indexer --config /home/myuser/sphinx.conf --all • --rotate is used for rotating indexes. Unless you have the situation where you can take the search function offline without troubling users, you will almost certainly need to keep search running whilst indexing new documents. --rotate creates a second index, parallel to the first (in the same place, simply including.new in the filenames). Once complete, indexer notifies searchd via sending the SIGHUP signal, and searchd will attempt to rename the indexes (renaming the existing ones to include.old and renaming the.new to replace them), and then start serving from the newer files.

Depending on the setting of, there may be a slight delay in being able to search the newer indexes. Example usage: $ indexer --rotate --all • --quiet tells indexer not to output anything, unless there is an error. Again, most used for cron-type, or other script jobs where the output is irrelevant or unnecessary, except in the event of some kind of error. Example usage: $ indexer --rotate --all --quiet • --noprogress does not display progress details as they occur; instead, the final status details (such as documents indexed, speed of indexing and so on are only reported at completion of indexing. In instances where the script is not being run on a console (or 'tty'), this will be on by default.

Example usage: $ indexer --rotate --all --noprogress • --buildstops reviews the index source, as if it were indexing the data, and produces a list of the terms that are being indexed. In other words, it produces a list of all the searchable terms that are becoming part of the index.

Note; it does not update the index in question, it simply processes the data 'as if' it were indexing, including running queries defined with sql_query_pre or sql_query_post. Outputfile.txt will contain the list of words, one per line, sorted by frequency with most frequent first, and N specifies the maximum number of words that will be listed; if sufficiently large to encompass every word in the index, only that many words will be returned.

Such a dictionary list could be used for client application features around 'Did you mean.' Functionality, usually in conjunction with --buildfreqs, below. Example: $ indexer myindex --buildstops word_freq.txt 1000 This would produce a document in the current directory, word_freq.txt with the 1,000 most common words in 'myindex', ordered by most common first. Note that the file will pertain to the last index indexed when specified with multiple indexes or --all (i.e.

The last one listed in the configuration file) • --buildfreqs works with --buildstops (and is ignored if --buildstops is not specified). As --buildstops provides the list of words used within the index, --buildfreqs adds the quantity present in the index, which would be useful in establishing whether certain words should be considered stopwords if they are too prevalent. It will also help with developing 'Did you mean.'

Features where you can how much more common a given word compared to another, similar one. Example: $ indexer myindex --buildstops word_freq.txt 1000 --buildfreqs This would produce the word_freq.txt as above, however after each word would be the number of times it occurred in the index in question. • --merge is used for physically merging indexes together, for example if you have a main+delta scheme, where the main index rarely changes, but the delta index is rebuilt frequently, and --merge would be used to combine the two.

The operation moves from right to left - the contents of src-index get examined and physically combined with the contents of dst-index and the result is left in dst-index. In pseudo-code, it might be expressed as: dst-index += src-index An example: $ indexer --merge main delta --rotate In the above example, where the main is the master, rarely modified index, and delta is the less frequently modified one, you might use the above to call indexer to combine the contents of the delta into the main index and rotate the indexes. • --merge-dst-range runs the filter range given upon merging. Specifically, as the merge is applied to the destination index (as part of --merge, and is ignored if --merge is not specified), indexer will also filter the documents ending up in the destination index, and only documents will pass through the filter given will end up in the final index. This could be used for example, in an index where there is a 'deleted' attribute, where 0 means 'not deleted'. Such an index could be merged with: $ indexer --merge main delta --merge-dst-range deleted 0 0 Any documents marked as deleted (value 1) would be removed from the newly-merged destination index.

It can be added several times to the command line, to add successive filters to the merge, all of which must be met in order for a document to become part of the final index. • --merge-killlists (and its shorter alias --merge-klists) changes the way kill lists are processed when merging indexes. By default, both kill lists get discarded after a merge. That supports the most typical main+delta merge scenario. With this option enabled, however, kill lists from both indexes get concatenated and stored into the destination index. Note that a source (delta) index kill list will be used to suppress rows from a destination (main) index at all times.

• --keep-attrs (added in version 2.1.1-beta) allows to reuse existing attributes on reindexing. Whenever the index is rebuilt, each new document id is checked for presence in the 'old' index, and if it already exists, its attributes are transferred to the 'new' index; if not found, attributes from the new index are used. If the user has updated attributes in the index, but not in the actual source used for the index, all updates will be lost when reindexing; using --keep-attrs enables saving the updated attribute values from the previous index • --dump-rows dumps rows fetched by SQL source(s) into the specified file, in a MySQL compatible syntax. Resulting dumps are the exact representation of data as received by indexer and help to repeat indexing-time issues.

• --verbose guarantees that every row that caused problems indexing (duplicate, zero, or missing document ID; or file field IO issues; etc) will be reported. By default, this option is off, and problem summaries may be reported instead. • --sighup-each is useful when you are rebuilding many big indexes, and want each one rotated into searchd as soon as possible. With --sighup-each, indexer will send a SIGHUP signal to searchd after successfully completing the work on each index. (The default behavior is to send a single SIGHUP after all the indexes were built.) • --nohup is useful when you want to check your index with indextool before actually rotating it.

Indexer won't send SIGHUP if this option is on. • --print-queries prints out SQL queries that indexer sends to the database, along with SQL connection and disconnection events. That is useful to diagnose and fix problems with SQL sources. Searchd command reference searchd is the second of the two principle tools as part of Sphinx. Searchd is the part of the system which actually handles searches; it functions as a server and is responsible for receiving queries, processing them and returning a dataset back to the different APIs for client applications.

Unlike indexer, searchd is not designed to be run either from a regular script or command-line calling, but instead either as a daemon to be called from init.d (on Unix/Linux type systems) or to be called as a service (on Windows-type systems), so not all of the command line options will always apply, and so will be build-dependent. Calling searchd is simply a case of: $ searchd [OPTIONS] The options available to searchd on all builds are. • --help ( -h for short) lists all of the parameters that can be called in your particular build of searchd. • --config ( -c for short) tells searchd to use the given file as its configuration, just as with indexer above. • --stop is used to asynchronously stop searchd, using the details of the PID file as specified in the sphinx.conf file, so you may also need to confirm to searchd which configuration file to use with the --config option. NB, calling --stop will also make sure any changes applied to the indexes with will be applied to the index files themselves. Example: $ searchd --config /home/myuser/sphinx.conf --stop • --stopwait is used to synchronously stop searchd.

--stop essentially tells the running instance to exit (by sending it a SIGTERM) and then immediately returns. --stopwait will also attempt to wait until the running searchd instance actually finishes the shutdown (eg. Saves all the pending attribute changes) and exits. Example: $ searchd --config /home/myuser/sphinx.conf --stopwait Possible exit codes are as follows. • 0 on success; • 1 if connection to running searchd daemon failed; • 2 if daemon reported an error during shutdown; • 3 if daemon crashed during shutdown.

• --status command is used to query running searchd instance status, using the connection details from the (optionally) provided configuration file. It will try to connect to the running instance using the first configured UNIX socket or TCP port. On success, it will query for a number of status and performance counter values and print them. You can use API call to access the very same counters from your application. Examples: $ searchd --status $ searchd --config /home/myuser/sphinx.conf --status • --pidfile is used to explicitly force using a PID file (where the searchd process number is stored) despite any other debugging options that say otherwise (for instance, --console). This is a debugging option. $ searchd --console --pidfile • --console is used to force searchd into console mode; typically it will be running as a conventional server application, and will aim to dump information into the log files (as specified in sphinx.conf).

Sometimes though, when debugging issues in the configuration or the daemon itself, or trying to diagnose hard-to-track-down problems, it may be easier to force it to dump information directly to the console/command line from which it is being called. Running in console mode also means that the process will not be forked (so searches are done in sequence) and logs will not be written to. (It should be noted that console mode is not the intended method for running searchd.) You can invoke it as such: $ searchd --config /home/myuser/sphinx.conf --console • --logdebug, --logdebugv, and --logdebugvv options enable additional debug output in the daemon log. They differ by the logging verboseness level. These are debugging options, they pollute the log a lot, and thus they should not be normally enabled.

(The normal use case for these is to enable them temporarily on request, to assist with some particularly complicated debugging session.) • --iostats is used in conjunction with the logging options (the query_log will need to have been activated in sphinx.conf) to provide more detailed information on a per-query basis as to the input/output operations carried out in the course of that query, with a slight performance hit and of course bigger logs. Further details are available under the section.

You might start searchd thus: $ searchd --config /home/myuser/sphinx.conf --iostats • --cpustats is used to provide actual CPU time report (in addition to wall time) in both query log file (for every given query) and status report (aggregated). It depends on clock_gettime() system call and might therefore be unavailable on certain systems. You might start searchd thus: $ searchd --config /home/myuser/sphinx.conf --cpustats • --port portnumber ( -p for short) is used to specify the port that searchd should listen on, usually for debugging purposes.

This will usually default to 9312, but sometimes you need to run it on a different port. Specifying it on the command line will override anything specified in the configuration file. The valid range is 0 to 65535, but ports numbered 1024 and below usually require a privileged account in order to run. An example of usage: $ searchd --port 9313 • --listen ( address ':' port port path ) [ ':' protocol ] (or -l for short) Works as --port, but allow you to specify not only the port, but full path, as IP address and port, or Unix-domain socket path, that searchd will listen on. Otherwords, you can specify either an IP address (or hostname) and port number, or just a port number, or Unix socket path.

If you specify port number but not the address, searchd will listen on all network interfaces. Unix path is identified by a leading slash. As the last param you can also specify a protocol handler (listener) to be used for connections on this socket. Supported protocol values are 'sphinx' (Sphinx 0.9.x API protocol) and 'mysql41' (MySQL protocol used since 4.1 upto at least 5.1). • --index (or -i for short) forces this instance of searchd only to serve the specified index. Like --port, above, this is usually for debugging purposes; more long-term changes would generally be applied to the configuration file itself.

Example usage: $ searchd --index myindex • --strip-path strips the path names from all the file names referenced from the index (stopwords, wordforms, exceptions, etc). This is useful for picking up indexes built on another machine with possibly different path layouts. • --replay-flags= switch, added in version 2.0.2-beta, can be used to specify a list of extra binary log replay options.

The supported options are. • --install installs searchd as a service into the Microsoft Management Console (Control Panel / Administrative Tools / Services). Any other parameters specified on the command line, where --install is specified will also become part of the command line on future starts of the service.

For example, as part of calling searchd, you will likely also need to specify the configuration file with --config, and you would do that as well as specifying --install. Once called, the usual start/stop facilities will become available via the management console, so any methods you could use for starting, stopping and restarting services would also apply to searchd. Example: C: WINDOWS system32>C: Sphinx bin searchd.exe --install --config C: Sphinx sphinx.conf If you wanted to have the I/O stats every time you started searchd, you would specify its option on the same line as the --install command thus: C: WINDOWS system32>C: Sphinx bin searchd.exe --install --config C: Sphinx sphinx.conf --iostats • --delete removes the service from the Microsoft Management Console and other places where services are registered, after previously installed with --install. Note, this does not uninstall the software or delete the indexes.

It means the service will not be called from the services systems, and will not be started on the machine's next start. If currently running as a service, the current instance will not be terminated (until the next reboot, or searchd is called with --stop). If the service was installed with a custom name (with --servicename), the same name will need to be specified with --servicename when calling to uninstall. Example: C: WINDOWS system32>C: Sphinx bin searchd.exe --delete • --servicename applies the given name to searchd when installing or deleting the service, as would appear in the Management Console; this will default to searchd, but if being deployed on servers where multiple administrators may log into the system, or a system with multiple searchd instances, a more descriptive name may be applicable. Note that unless combined with --install or --delete, this option does not do anything. Example: C: WINDOWS system32>C: Sphinx bin searchd.exe --install --config C: Sphinx sphinx.conf --servicename SphinxSearch • --ntservice is the option that is passed by the Management Console to searchd to invoke it as a service on Windows platforms. It would not normally be necessary to call this directly; this would normally be called by Windows when the service would be started, although if you wanted to call this as a regular service from the command-line (as the complement to --console) you could do so in theory.

• --safetrace forces searchd to only use system backtrace() call in crash reports. In certain (rare) scenarios, this might be a 'safer' way to get that report. This is a debugging option. • --nodetach switch (Linux only) tells searchd not to detach into background. This will also cause log entry to be printed out to console. Query processing operates as usual. This is a debugging option.

Last but not least, as every other daemon, searchd supports a number of signals. Spelldump command reference spelldump is one of the helper tools within the Sphinx package. It is used to extract the contents of a dictionary file that uses ispell or MySpell format, which can help build word lists for wordforms - all of the possible forms are pre-built for you. Its general usage is: spelldump [options] [result] [locale-name] The two main parameters are the dictionary's main file and its affix file; usually these are named as [language-prefix].dict and [language-prefix].aff and will be available with most common Linux distributions, as well as various places online. [result] specifies where the dictionary data should be output to, and [locale-name] additionally specifies the locale details you wish to use. There is an additional option, -c [file], which specifies a file for case conversion details.

Examples of its usage are: spelldump en.dict en.aff spelldump ru.dict ru.aff ru.txt ru_RU.CP1251 spelldump ru.dict ru.aff ru.txt.1251 The results file will contain a list of all the words in the dictionary in alphabetical order, output in the format of a wordforms file, which you can use to customize for your specific circumstances. An example of the result file: zone >zone zoned >zoned zoning >zoning.

• --checkconfig just loads and verifies the config file to check if it's valid, without syntax errors. This option was added in version 2.1.1-beta. • --build-infixes INDEXNAME build infixes for an existing dict=keywords index (upgrades.sph,.spi in place).

You can use this option for legacy index files that already use dict=keywords, but now need to support infix searching too; updating the index files with indextool may prove easier or faster than regenerating them from scratch with indexer. This option was added in version 2.1.1-beta. • --dumpheader FILENAME.sph quickly dumps the provided index header file without touching any other index files or even the configuration file. The report provides a breakdown of all the index settings, in particular the entire attribute and field list.

Prior to 0.9.9-rc2, this command was present in now removed CLI search utility. • --dumpconfig FILENAME.sph dumps the index definition from the given index header file in (almost) compliant sphinx.conf file format. Added in version 2.0.1-beta. • --dumpheader INDEXNAME dumps index header by index name with looking up the header path in the configuration file. • --dumpdict INDEXNAME dumps dictionary. This was added in version 2.1.1-beta. • --dumpdocids INDEXNAME dumps document IDs by index name.

It takes the data from attribute (.spa) file and therefore requires docinfo=extern to work. • --dumphitlist INDEXNAME KEYWORD dumps all the hits (occurrences) of a given keyword in a given index, with keyword specified as text. • --dumphitlist INDEXNAME --wordid ID dumps all the hits (occurrences) of a given keyword in a given index, with keyword specified as internal numeric ID. • --fold INDEXNAME OPTFILE This options is useful too see how actually tokenizer proceeds input.

You can feed indextool with text from file if specified or from stdin otherwise. The output will contain spaces instead of separators (accordingly to your charset_table settings) and lowercased letters in words.

• --htmlstrip INDEXNAME filters stdin using HTML stripper settings for a given index, and prints the filtering results to stdout. Note that the settings will be taken from sphinx.conf, and not the index header. • --morph INDEXNAME applies morphology to the given stdin and prints the result to stdout. • --check INDEXNAME checks the index data files for consistency errors that might be introduced either by bugs in indexer and/or hardware faults. Starting with version 2.1.1-beta, --check also works on RT indexes, RAM and disk chunks. • --strip-path strips the path names from all the file names referenced from the index (stopwords, wordforms, exceptions, etc).

This is useful for checking indexes built on another machine with possibly different path layouts. • --optimize-rt-klists optimizes the kill list memory use in the disk chunk of a given RT index.

That is a one-off optimization intended for rather old RT indexes, created by development versions prior to 1.10-beta release. As of 1.10-beta releases, this kill list optimization (purging) should happen automatically, and there should never be a need to use this option. • --rotate works only with --check and defines whether to check index waiting for rotation, i.e. With.new extension. This is useful when you want to check your index before actually using it. Wordbreaker command reference wordbreaker is one of the helper tools within the Sphinx package, introduced in version 2.1.1-beta.

It is used to split compound words, as usual in URLs, into its component words. For example, this tool can split 'lordoftherings' into its four component words, or 'into 'man of steel warner bros'. This helps searching, without requiring prefixes or infixes: searching for 'sphinx' wouldn't match 'sphinxsearch' but if you break the compound word and index the separate components, you'll get a match without the costs of prefix and infix larger index files. Examples of its usage are: echo manofsteel bin/wordbreaker -dict dict.txt split The input stream will be separated in words using the -dict dictionary file. (The dictionary should match the language of the compound word.) The split command breaks words from the standard input, and outputs the result in the standard output.

There are also test and bench commands that let you test the splitting quality and benchmark the splitting functionality. Wordbreaker Wordbreaker needs a dictionary to recognize individual substrings within a string. To differentiate between different guesses, it uses the relative frequency of each word in the dictionary: higher frequency means higher split probability. You can generate such a file using the indexer tool, as in indexer --buildstops dict.txt 100000 --buildfreqs myindex -c /path/to/sphinx.conf which will write the 100,000 most frequent words, along with their counts, from myindex into dict.txt. The output file is a text file, so you can edit it by hand, if need be, to add or remove words. See for more on this tool.

• Column list clause. Column names, arbitrary expressions, and star ('*') are all allowed (ie. SELECT id, group_id*123+456 AS expr1 FROM test1 will work).

Unlike in regular SQL, all computed expressions must be aliased with a valid identifier. Starting with version 2.0.1-beta, AS is optional. • EXIST() function (added in version 2.1.1-beta) is supported. EXIST ( 'attr-name', default-value ) replaces non-existent columns with default values. It returns either a value of an attribute specified by 'attr-name', or 'default-value' if that attribute does not exist.

As of 2.1.1-beta it does not support STRING or MVA attributes. This function is handy when you are searching through several indexes with different schemas. SELECT *, EXIST('gid', 6) as cnd FROM i1, i2 WHERE cnd>5 • SNIPPET() function (added in version 2.1.1-beta) is supported. This is a wrapper around the snippets functionality, similar to what is available via CALL SNIPPETS. The first two arguments are: the text to highlight, and a query. Starting with 2.2-1-beta it's possible to pass to function.

The intended use is as follows: SELECT id, SNIPPET(myUdf(id), 'my.query', 'limit=100') FROM myIndex WHERE MATCH('my.query') where myUdf() would be a UDF that fetches a document by its ID from some external storage. This enables applications to fetch the entire result set directly from Sphinx in one query, without having to separately fetch the documents in the application and then send them back to Sphinx for highlighting. SNIPPET() is a so-called 'post limit' function, meaning that computing snippets is postponed not just until the entire final result set is ready, but even after the LIMIT clause is applied. For example, with a LIMIT 20,10 clause, SNIPPET() will be called at most 10 times.

Table functions is a mechanism of post-query result set processing. It was added in 2.2.1-beta. Table functions take an arbitrary result set as their input, and return a new, processed set as their output. The first argument should be the input result set, but a table function can optionally take and handle more arguments. Table functions can completely change the result set, including the schema. For now, only built in table functions are supported. UDFs are planned when the internal call interface is stabilized.

Table functions work for both outer SELECT and nested SELECT. • 'agent_query_timeout' - integer (max time in milliseconds to wait for remote queries to complete, see under Index configuration options for details) • 'boolean_simplify' - 0 or 1, enables simplifying the query to speed it up • 'comment' - string, user comment that gets copied to a query log file • 'cutoff' - integer (max found matches threshold) • 'field_weights' - a named integer list (per-field user weights for ranking) • 'global_idf' - use global statistics (frequencies) from the for IDF computations, rather than the local index statistics. Added in version 2.1.1-beta. • 'idf' - a quoted, comma-separated list of IDF computation flags. Added in version 2.1.1-beta.

Known flags are. 8.4. SHOW WARNINGS syntax SHOW WARNINGS SHOW WARNINGS statement, introduced in version 0.9.9-rc2, can be used to retrieve the warning produced by the latest query. The error message will be returned along with the query itself: mysql>SELECT * FROM test1 WHERE MATCH('@@title hello') G ERROR 1064 (42000): index test1: syntax error, unexpected TOK_FIELDLIMIT near '@title hello' mysql>SELECT * FROM test1 WHERE MATCH('@title -hello') G ERROR 1064 (42000): index test1: query is non-computable (single NOT operator) mysql>SELECT * FROM test1 WHERE MATCH('test doc'/3') G *************************** 1. Row *************************** id: 4 weight: 2500 group_id: 2 date_added: 1 row in set, 1 warning (0.00 sec) mysql>SHOW WARNINGS G *************************** 1.

Row *************************** Level: warning Code: 1000 Message: quorum threshold too high (words=2, thresh=3); replacing quorum operator with AND operator 1 row in set (0.00 sec). 8.5. SHOW STATUS syntax SHOW STATUS [ LIKE pattern ] SHOW STATUS, introduced in version 0.9.9-rc2, displays a number of useful performance counters. IO and CPU counters will only be available if searchd was started with --iostats and --cpustats switches respectively.

8.8. DELETE syntax DELETE FROM index WHERE where_condition DELETE statement, introduced in version 1.10-beta, is only supported for RT indexes and for distributed which contains only RT indexes as agents It deletes existing rows (documents) from an existing index based on ID. Index is the name of RT index from which the row should be deleted. Where_condition has the same syntax as in the SELECT statement (see for details). 8.9. SET syntax SET [GLOBAL] server_variable_name = value SET [INDEX index_name] GLOBAL @user_variable_name = (int_val1 [, int_val2.]) SET NAMES value SET @@dummy_variable = ignored_value SET statement, introduced in version 1.10-beta, modifies a variable value. The variable names are case-insensitive.

No variable value changes survive server restart. SET NAMES statement and SET @@variable_name syntax, both introduced in version 2.0.2-beta, do nothing. They were implemented to maintain compatibility with 3rd party MySQL client libraries, connectors, and frameworks that may need to run this statement when connecting. There are the following classes of the variables.

• per-session server variable (1.10-beta and above) • global server variable (2.0.1-beta and above) • global user variable (2.0.1-beta and above) • global distributed variable (2.2.3-beta and above) Global user variables are shared between concurrent sessions. Currently, the only supported value type is the list of BIGINTs, and these variables can only be used along with IN() for filtering purpose.

The intended usage scenario is uploading huge lists of values to searchd (once) and reusing them (many times) later, saving on network overheads. Starting with 2.2.3-beta, global user variables might be either transferred to all agents of distributed index or set locally in case of local index defined at distibuted index. 8.14. CALL SNIPPETS syntax CALL SNIPPETS(data, index, query[, opt_value AS opt_name[.]]) CALL SNIPPETS statement, introduced in version 1.10-beta, builds a snippet from provided data and query, using specified index settings. Data is the source data to extract a snippet from.

It could be a single string, or the list of the strings enclosed in curly brackets. Index is the name of the index from which to take the text processing settings. Query is the full-text query to build snippets for.

Additional options are documented in. Usage example: CALL SNIPPETS('this is my document text', 'test1', 'hello world', 5 AS around, 200 AS limit); CALL SNIPPETS(('this is my document text','this is my another text'), 'test1', 'hello world', 5 AS around, 200 AS limit); CALL SNIPPETS(('data/doc1.txt','data/doc2.txt','/home/sphinx/doc3.txt'), 'test1', 'hello world', 5 AS around, 200 AS limit, 1 AS load_files). 8.15. CALL KEYWORDS syntax CALL KEYWORDS(text, index [, 1]) CALL KEYWORDS statement, introduced in version 1.10-beta, splits text into particular keywords. It returns tokenized and normalized forms of the keywords, and, optionally, keyword statistics.

Since version 2.2.2-beta it also returns the position of each keyword in the query and all forms of tokenized keywords in the case that lemmatizers were used. Text is the text to break down to keywords. Index is the name of the index from which to take the text processing settings. Hits is an optional boolean parameter that specifies whether to return document and hit occurrence statistics. 8.16. SHOW TABLES syntax SHOW TABLES [ LIKE pattern ] SHOW TABLES statement, introduced in version 2.0.1-beta, enumerates all currently active indexes along with their types. As of 2.0.1-beta, existing index types are local, distributed, and rt respectively. Example: mysql>SHOW TABLES; +-------+-------------+ Index Type +-------+-------------+ dist1 distributed rt rt test1 local test2 local +-------+-------------+ 4 rows in set (0.00 sec) Starting from version 2.1.1-beta, an optional LIKE clause is supported.

Refer to for its syntax details. Mysql>SHOW TABLES LIKE '%4'; +-------+-------------+ Index Type +-------+-------------+ dist4 distributed +-------+-------------+ 1 row in set (0.00 sec). 8.22. SHOW CHARACTER SET syntax SHOW CHARACTER SET Added in version 2.1.1-beta, this is currently a placeholder query that does nothing and reports that a UTF-8 character set is available.

It was added in order to keep compatibility with frameworks and connectors that automatically execute this statement. Mysql>SHOW CHARACTER SET; +---------+---------------+-------------------+--------+ Charset Description Default collation Maxlen +---------+---------------+-------------------+--------+ utf8 UTF-8 Unicode utf8_general_ci 3 +---------+---------------+-------------------+--------+ 1 row in set (0.00 sec). 8.23. UPDATE syntax UPDATE index SET col1 = newval1 [.] WHERE where_condition [OPTION opt_name = opt_value [.]] UPDATE statement was added in version 2.0.1-beta. Multiple attributes and values can be specified in a single statement.

Both RT and disk indexes are supported. As of version 2.0.2-beta, all attributes types (int, bigint, float, MVA), except for strings and JSON attributes, can be dynamically updated. Previously, some of these types were not supported.

Where_condition (also added in 2.0.2-beta) has the same syntax as in the SELECT statement (see for details). When assigning the out-of-range values to 32-bit attributes, they will be trimmed to their lower 32 bits without a prompt.

For example, if you try to update the 32-bit unsigned int with a value of, the value of 1 will actually be stored, because the lower 32 bits of (0x100000001 in hex) amount to 1 (0x00000001 in hex). MVA values sets for updating (and also for INSERT or REPLACE, refer to ) must be specified as comma-separated lists in parentheses. To erase the MVA value, just assign () to it. Starting from 2.2.1-beta version UPDATE can be used to update integer and float values in JSON array. No strings, arrays and other types yet.

Mysql>UPDATE myindex SET enabled=0 WHERE id=123; Query OK, 1 rows affected (0.00 sec) mysql>UPDATE myindex SET bigattr=-00, fattr=3465.23, mvattr1=(3,6,4), mvattr2=() WHERE MATCH('hehe') AND enabled=1; Query OK, 148 rows affected (0.01 sec) OPTION clause. This is a Sphinx specific extension that lets you control a number of per-update options.

The syntax is: OPTION = [. ] The list of allowed options are the same as for statement. Specifically for UPDATE statement you can use these options. 8.25. ATTACH INDEX syntax ATTACH INDEX diskindex TO RTINDEX rtindex ATTACH INDEX statement, added in version 2.0.2-beta, lets you move data from a regular disk index to a RT index.

After a successful ATTACH, the data originally stored in the source disk index becomes a part of the target RT index, and the source disk index becomes unavailable (until the next rebuild). ATTACH does not result in any index data changes. Basically, it just renames the files (making the source index a new disk chunk of the target RT index), and updates the metadata. So it is a generally quick operation which might (frequently) complete as fast as under a second.

Note that when an index is attached to an empty RT index, the fields, attributes, and text processing settings (tokenizer, wordforms, etc) from the source index are copied over and take effect. The respective parts of the RT index definition from the configuration file will be ignored. As of 2.0.2-beta, ATTACH INDEX comes with a number of restrictions. Most notably, the target RT index is currently required to be empty, making ATTACH INDEX a one-time conversion operation only. Those restrictions may be lifted in future releases, as we add the needed functionality to the RT indexes. The complete list is as follows. • Target RT index needs to be empty.

(See ) • Source disk index needs to have index_sp=0, boundary_step=0, stopword_step=1. • Source disk index needs to have an empty index_zones setting. 8.26. FLUSH RTINDEX syntax FLUSH RTINDEX rtindex FLUSH RTINDEX statement, added in version 2.0.2-beta, forcibly flushes RT index RAM chunk contents to disk. Backing up a RT index is as simple as copying over its data files, followed by the binary log. However, recovering from that backup means that all the transactions in the log since the last successful RAM chunk write would need to be replayed. Those writes normally happen either on a clean shutdown, or periodically with a (big enough!) interval between writes specified in directive.

So such a backup made at an arbitrary point in time just might end up with way too much binary log data to replay. FLUSH RTINDEX forcibly writes the RAM chunk contents to disk, and also causes the subsequent cleanup of (now-redundant) binary log files. Thus, recovering from a backup made just after FLUSH RTINDEX should be almost instant. Mysql>FLUSH RTINDEX rt; Query OK, 0 rows affected (0.05 sec). 8.27. FLUSH RAMCHUNK syntax FLUSH RAMCHUNK rtindex FLUSH RAMCHUNK statement, added in version 2.1.2-release, forcibly creates a new disk chunk in a RT index. Normally, RT index would flush and convert the contents of the RAM chunk into a new disk chunk automatically, once the RAM chunk reaches the maximum allowed size. However, for debugging and testing it might be useful to forcibly create a new disk chunk, and FLUSH RAMCHUNK statement does exactly that.

Note that using FLUSH RAMCHUNK increases RT index fragmentation. Most likely, you want to use FLUSH RTINDEX instead. We suggest that you abstain from using just this statement unless you're absolutely sure what you're doing. As the right way is to issue FLUSH RAMCHUNK with following command.

Such combo allows to keep RT index fragmentation on minimum. Mysql>FLUSH RAMCHUNK rt; Query OK, 0 rows affected (0.05 sec). 8.28. TRUNCATE RTINDEX syntax TRUNCATE RTINDEX rtindex TRUNCATE RTINDEX statement, added in version 2.1.1-beta, clears the RT index completely. It disposes the in-memory data, unlinks all the index data files, and releases the associated binary logs.

Mysql>TRUNCATE RTINDEX rt; Query OK, 0 rows affected (0.05 sec) You may want to use this if you are using RT indices as 'delta index' files; when you build the main index, you need to wipe the delta index, and thus TRUNCATE RTINDEX. You also need to use this command before attaching an index; see. 8.29. SHOW AGENT STATUS SHOW AGENT ['agent' 'index' index] STATUS [ LIKE pattern ] Displays the statistic of or distributed index. It includes the values like the age of the last request, last answer, the number of different kind of errors and successes, etc. The statistic is shown for every agent for last 1, 5 and 15 intervals, each of them of seconds. The command exists only in sphinxql.

8.30. SHOW PROFILE syntax SHOW PROFILE SHOW PROFILE statement, added in version 2.1.1-beta, shows a detailed execution profile of the previous SQL statement executed in the current SphinxQL session. Also, profiling must be enabled in the current session before running the statement to be instrumented. That can be done with a SET profiling=1 statement. By default, profiling is disabled to avoid potential performance implications, and therefore the profile will be empty.

• unknown, generic catch-all state. Accounts for both not-yet-instrumented code, or just small miscellaneous tasks that do not really belong in any other state, but are too small to deserve their own state.

• net_read, reading the query from the network (that is, the application). • io, generic file IO time.

• dist_connect, connecting to remote agents in the distributed index case. • sql_parse, parsing the SphinxQL syntax. • dict_setup, dictionary and tokenizer setup.

• parse, parsing the full-text query syntax. • transforms, full-text query transformations (wildcard and other expansions, simplification, etc). • init, initializing the query evaluation. • open, opening the index files.

• read_docs, IO time spent reading document lists. • read_hits, IO time spent reading keyword positions. • get_docs, computing the matching documents. • get_hits, computing the matching positions.

• filter, filtering the full-text matches. • rank, computing the relevance rank. • sort, sorting the matches. • finalize, finalizing the per-index search result set (last stage expressions, etc). • dist_wait, waiting for the remote results from the agents in the distributed index case.

• aggregate, aggregating multiple result sets. • net_write, writing the result set to the network.

• indexed_documents and indexed_bytes, number of the documents indexed and their text size in bytes, respectively. • field_tokens_XXX, sums of per-field lengths (in tokens) over the entire index (that is used internally in BM25A and BM25F functions for ranking purposes). Only available for indexes built with index_field_lengths=1. • ram_bytes, total size (in bytes) of the RAM-resident index portion. Mysql>SHOW INDEX lj STATUS; +--------------------+-------------+ Variable_name Value +--------------------+-------------+ index_type disk indexed_documents 2495219 indexed_bytes 9 field_tokens_title 6999145 field_tokens_body total_tokens ram_bytes 305963599 disk_bytes mem_limit 536870912 +--------------------+-------------+ 8 rows in set (0.00 sec). 8.33. OPTIMIZE INDEX syntax OPTIMIZE INDEX index_name Available since version 2.1.1-beta, OPTIMIZE statement enqueues a RT index for optimization in a background thread. Over time, RT indexes can grow fragmented into many disk chunks and/or tainted with deleted, but unpurged data, impacting search performance.

When that happens, they can be optimized. Basically, the optimization pass merges together disk chunks pairs, purging off documents suppressed by K-list as it goes. That is a lengthy and IO intensive process, so to limit the impact, all the actual merge work is executed serially in a special background thread, and the OPTIMIZE statement simply adds a job to its queue. Currently, there is no way to check the index or queue status (that might be added in the future to the SHOW INDEX STATUS and SHOW STATUS statements respectively). The optimization thread can be IO-throttled, you can control the maximum number of IOs per second and the maximum IO size with and directives respectively. The optimization jobs queue is lost on daemon crash.

The RT index being optimized stays online and available for both searching and updates at (almost) all times during the optimization. It gets locked (very) briefly every time that a pair of disk chunks is merged successfully, to rename the old and the new files, and update the index header. At the moment, OPTIMIZE needs to be issued manually, the indexes will not be optimized automatically. That might change in the future releases. Mysql>OPTIMIZE INDEX rt; Query OK, 0 rows affected (0.00 sec). 8.34. SHOW PLAN syntax SHOW PLAN SHOW PLAN statement, added in 2.1.2-release, displays the execution plan of the previous SELECT statement. The plan gets generated and stored during the actual execution, so profiling must be enabled in the current session before running that statement.

That can be done with a SET profiling=1 statement. Here's a complete instrumentation example: mysql>SET profiling=1 G Query OK, 0 rows affected (0.00 sec) mysql>SELECT id FROM lj WHERE MATCH('the i') LIMIT 1 G *************************** 1.

Row *************************** id: 39815 1 row in set (1.53 sec) mysql>SHOW PLAN G *************************** 1. Row *************************** Variable: transformed_tree Value: AND( AND(KEYWORD(the, querypos=1)), AND(KEYWORD(i, querypos=2))) 1 row in set (0.00 sec) And here's a less trivial example that shows how the actually evaluated query tree can be rather different from the original one because of expansions and other transformations: mysql>SELECT * FROM test WHERE MATCH('@title abc* @body hey') G SHOW PLAN G. *************************** 1. Row *************************** Variable: transformed_tree Value: AND( OR(fields=(title), KEYWORD(abcx, querypos=1, expanded), KEYWORD(abcm, querypos=1, expanded)), AND(fields=(body), KEYWORD(hey, querypos=2))) 1 row in set (0.00 sec).

8.37. DROP PLUGIN syntax DROP PLUGIN plugin_name TYPE 'plugin_type' Added in 2.2.2-beta. Markes the specified plugin for unloading. The unloading is not immediate, because the concurrent queries might be using it. However, after a DROP new queries will not be able to use it.

Then, once all the currently executing queries using it are completed, the plugin will be unloaded. Once all the plugins from the given library are unloaded, the library is also automatically unloaded. Mysql>DROP PLUGIN myranker TYPE 'ranker'; Query OK, 0 rows affected (0.00 sec). 8.38. SHOW PLUGINS syntax SHOW PLUGINS Added in 2.2.2-beta. Displays all the loaded plugins and UDFs. 'Type' column should be one of the udf, ranker, index_token_filter, or query_token_filter.

'Users' column is the number of thread that are currently using that plugin in a query. 'Extra' column is intended for various additional plugin-type specific information; currently, it shows the return type for the UDFs and is empty for all the other plugin types. Mysql>SHOW PLUGINS; +------+----------+----------------+-------+-------+ Type Name Library Users Extra +------+----------+----------------+-------+-------+ udf sequence udfexample.dll 0 INT +------+----------+----------------+-------+-------+ 1 row in set (0.00 sec). • thread id • connection protocol, possible values are sphinxapi and sphinxql • thread state, possible values are handshake, net_read, net_write, query, net_idle • time since the current state was changed (in seconds, with microsecond precision) • information about queries The 'Info' column will be cut at the width you've specified in the 'columns=width' option (notice the third row in the example table below). This column will contain raw SphinxQL queries and, if there are API queries, full text syntax and comments will be displayed.

With an API-snippet, the data size will be displayed along with the query. 8.41. Comment syntax Since version 2.0.1-beta, SphinxQL supports C-style comment syntax.

Everything from an opening /* sequence to a closing */ sequence is ignored. Comments can span multiple lines, can not nest, and should not get logged. MySQL specific /*! */ comments are also currently ignored. (As the comments support was rather added for better compatibility with mysqldump produced dumps, rather than improving general query interoperability between Sphinx and MySQL.) SELECT /*! SQL_CALC_FOUND_ROWS */ col1 FROM table1 WHERE. 8.43. SphinxQL upgrade notes, version 2.0.1-beta This section only applies to existing applications that use SphinxQL versions prior to 2.0.1-beta.

In previous versions, SphinxQL just wrapped around SphinxAPI and inherited its magic columns and column set quirks. Essentially, SphinxQL queries could return (slightly) different columns and in a (slightly) different order than it was explicitly requested in the query. Namely, weight magic column (which is not a real column in any index) was added at all times, and GROUP BY related @count, @group, and @distinct magic columns were conditionally added when grouping. Also, the order of columns (attributes) in the result set was actually taken from the index rather than the query. (So if you asked for columns C, B, A in your query but they were in the A, B, C order in the index, they would have been returned in the A, B, C order.) In version 2.0.1-beta, we fixed that. SphinxQL is now more SQL compliant (and will be further brought in as much compliance with standard SQL syntax as possible). The important changes are as follows.

• @ID magic name is deprecated in favor of ID. Document ID is considered an attribute. • WEIGHT is no longer implicitly returned, because it is not actually a column (an index attribute), but rather an internal function computed per each row (a match).

You have to explicitly ask for it, using the WEIGHT() function. (The requirement to alias the result will be lifted in the next release.) SELECT id, WEIGHT() w FROM myindex WHERE MATCH('test') • You can now use quoted reserved keywords as aliases. The quote character is backtick ('`', ASCII code 96 decimal, 60 hex). One particularly useful example would be returning weight column like the old mode: SELECT id, WEIGHT() `weight` FROM myindex WHERE MATCH('test') • The column order is now different and should now match the one explicitly defined in the query. So if you are accessing columns based on their position in the result set rather than the name (for instance, by using mysql_fetch_row() rather than mysql_fetch_assoc() in PHP), check and fix the order of columns in your queries.

• SELECT * return the columns in index order, as it used to, including the ID column. However, SELECT * does not automatically return WEIGHT(). To update such queries in case you access columns by names, simply add it to the query: SELECT *, WEIGHT() `weight` FROM myindex WHERE MATCH('test') Otherwise, i.e., in case you rely on column order, select ID, weight, and then other columns: SELECT id, *, WEIGHT() `weight` FROM myindex WHERE MATCH('test') • Magic @count and @distinct attributes are no longer implicitly returned. You now have to explicitly ask for them when using GROUP BY. (Also note that you currently have to alias them; that requirement will be lifted in the future.) SELECT gid, COUNT(*) q FROM myindex WHERE MATCH('test') GROUP BY gid ORDER BY q DESC.

Table of Contents There is a number of native searchd client API implementations for Sphinx. As of time of this writing, we officially support our own PHP, Python, and Java implementations.

There also are third party free, open-source API implementations for Perl, Ruby, and C++. The reference API implementation is in PHP, because (we believe) Sphinx is most widely used with PHP than any other language. This reference documentation is in turn based on reference PHP API, and all code samples in this section will be given in PHP.

However, all other APIs provide the same methods and implement the very same network protocol. Therefore the documentation does apply to them as well. There might be minor differences as to the method naming conventions or specific data structures used. But the provided functionality must not differ across languages. 9.1.2. GetLastWarning Prototype: function GetLastWarning () Returns last warning message, as a string, in human readable format.

If there were no warnings during the previous API call, empty string is returned. You should call it to verify whether your request (such as ) was completed but with warnings. For instance, search query against a distributed index might complete successfully even if several remote agents timed out.

In that case, a warning message would be produced. The warning message is not reset by this call; so you can safely call it several times if needed. 9.1.4. SetRetries Prototype: function SetRetries ( $count, $delay=0 ) Sets distributed retry count and delay. On temporary failures searchd will attempt up to $count retries per agent. $delay is the delay between the retries, in milliseconds. Retries are disabled by default. Note that this call will not make the API itself retry on temporary failure; it only tells searchd to do so.

Currently, the list of temporary failures includes all kinds of connect() failures and maxed out (too busy) remote agents. 9.1.5. SetConnectTimeout Prototype: function SetConnectTimeout ( $timeout ) Sets the time allowed to spend connecting to the server before giving up. Under some circumstances, the server can be delayed in responding, either due to network delays, or a query backlog. In either instance, this allows the client application programmer some degree of control over how their program interacts with searchd when not available, and can ensure that the client application does not fail due to exceeding the script execution limits (especially in PHP). In the event of a failure to connect, an appropriate error code should be returned back to the application in order for application-level error handling to advise the user.

9.1.6. SetArrayResult Prototype: function SetArrayResult ( $arrayresult ) PHP specific. Controls matches format in the search results set (whether matches should be returned as an array or a hash). $arrayresult argument must be boolean. If $arrayresult is false (the default mode), matches will returned in PHP hash format with document IDs as keys, and other information (weight, attributes) as values. If $arrayresult is true, matches will be returned as a plain array with complete per-match information including document ID. Introduced along with GROUP BY support on MVA attributes. Group-by-MVA result sets may contain duplicate document IDs.

Thus they need to be returned as plain arrays, because hashes will only keep one entry per document ID. 9.2.1. SetLimits Prototype: function SetLimits ( $offset, $limit, $max_matches=1000, $cutoff=0 ) Sets offset into server-side result set ( $offset) and amount of matches to return to client starting from that offset ( $limit). Can additionally control maximum server-side result set size for current query ( $max_matches) and the threshold amount of matches to stop searching at ( $cutoff). All parameters must be non-negative integers. First two parameters to SetLimits() are identical in behavior to MySQL LIMIT clause.

They instruct searchd to return at most $limit matches starting from match number $offset. The default offset and limit settings are 0 and 20, that is, to return first 20 matches. Max_matches setting controls how much matches searchd will keep in RAM while searching. All matching documents will be normally processed, ranked, filtered, and sorted even if max_matches is set to 1. But only best N documents are stored in memory at any given moment for performance and RAM usage reasons, and this setting controls that N.

Note that there are two places where max_matches limit is enforced. Per-query limit is controlled by this API call, but there also is per-server limit controlled by max_matches setting in the config file.

To prevent RAM usage abuse, server will not allow to set per-query limit higher than the per-server limit. You can't retrieve more than max_matches matches to the client application. The default limit is set to 1000. Normally, you must not have to go over this limit. One thousand records is enough to present to the end user. And if you're thinking about pulling the results to application for further sorting or filtering, that would be much more efficient if performed on Sphinx side.

$cutoff setting is intended for advanced performance control. It tells searchd to forcibly stop search query once $cutoff matches had been found and processed. 9.2.2. SetMaxQueryTime Prototype: function SetMaxQueryTime ( $max_query_time ) Sets maximum search query time, in milliseconds. Parameter must be a non-negative integer. Default value is 0 which means 'do not limit'. Similar to $cutoff setting from, but limits elapsed query time instead of processed matches count. Local search queries will be stopped once that much time has elapsed.

Note that if you're performing a search which queries several local indexes, this limit applies to each index separately. 9.2.3. SetOverride DEPRECATED Prototype: function SetOverride ( $attrname, $attrtype, $values ) Sets temporary (per-query) per-document attribute value overrides. Only supports scalar attributes. $values must be a hash that maps document IDs to overridden attribute values.

Introduced in version 0.9.9-rc1. Override feature lets you 'temporary' update attribute values for some documents within a single query, leaving all other queries unaffected. This might be useful for personalized data. For example, assume you're implementing a personalized search function that wants to boost the posts that the user's friends recommend.

Such data is not just dynamic, but also personal; so you can't simply put it in the index because you don't want everyone's searches affected. Overrides, on the other hand, are local to a single query and invisible to everyone else. So you can, say, setup a 'friends_weight' value for every document, defaulting to 0, then temporary override it with 1 for documents 123, 456 and 789 (recommended by exactly the friends of current user), and use that value when ranking.

HWK Update for Twister, NBox, Tornado, UFS3, Excalibur Box's This update clips into your existing box giving you extra support for more models A Twister, Tornado, UFS2, UFS3, UFS-Excalibur or NBox is required to use this module Supported phone brands • Nokia • Samsung • SonyEricsson / LG 3G and Sharp • Now Supports Flashing Nokia BB5 Platform (6680, 6630 etc.) • NEW Update LG 2G Support Added 17/09/05 • View updates and release notes!!! April 4 Android UFST V1.0.5.4 Release For ALL Users for UFST and UFS Turbo Users Only. We Have Moved Dear Customers, We are moving to our new state of the art.COM website The new site is 'BREXIT READY' and 100% SECURE, it has newer features for Tax free shopping for EU Shoppers with a valid VAT number, and Tax Free shopping for ALL customers outside Europe Easier registration, and simple checkout features, as well as login with facebook or Google accounts Please update your bookmarks, as the current fonefunshop.co.uk site will be closing down in due course. If you need any assistance please contact us.