Integration of Sphinx with 1C-Bitrix

Sphinx Integration with Bitrix CMS

Sphinx (and its fork Manticore Search) is a specialized search engine that indexes data directly from MySQL. This is its main advantage over Elasticsearch when integrating with Bitrix: Sphinx reads data from tables b_iblock_element, b_iblock_element_property, b_search_content via standard MySQL connector. No need to write a separate data exporter — the data source is described through SQL queries in the Sphinx config.

Data Source Configuration

Sphinx reads data through a source — an SQL query executed during reindexing. Example config for a product catalog:

source bitrix_catalog
{
    type            = mysql
    sql_host        = localhost
    sql_user        = bitrix
    sql_pass        = password
    sql_db          = bitrix_db
    sql_port        = 3306

    sql_query = \
        SELECT \
            e.ID, \
            e.IBLOCK_ID, \
            e.NAME, \
            e.DETAIL_TEXT, \
            e.CODE, \
            UNIX_TIMESTAMP(e.TIMESTAMP_X) AS updated_at \
        FROM b_iblock_element e \
        WHERE e.IBLOCK_ID IN (5, 6) \
          AND e.ACTIVE = 'Y' \
          AND e.WF_STATUS_ID = 1

    sql_attr_uint  = IBLOCK_ID
    sql_attr_uint  = updated_at
    sql_field_string = NAME
}

sql_attr_uint declares numeric attributes — used for filtering (WHERE IBLOCK_ID = 5), but not for full-text search. sql_field_string — string field available for both search and return in results.

Including Product Properties

For faceted filtering in search, product properties are needed. Add them via sql_joined_field or separate sql_query_attr:

sql_attr_multi = uint PROPERTY_COLOR FROM query; \
    SELECT e.ID, p.VALUE_NUM \
    FROM b_iblock_element e \
    JOIN b_iblock_element_prop_s5 p ON p.IBLOCK_ELEMENT_ID = e.ID \
    WHERE e.IBLOCK_ID = 5

b_iblock_element_prop_s5 — properties table for infoblock with ID 5. Each infoblock has its own table (number at end = IBLOCK_ID). This is a Bitrix peculiarity to account for when writing queries.

Morphology Setup

Sphinx supports Russian morphology through built-in stemmer:

index bitrix_catalog
{
    source          = bitrix_catalog
    path            = /var/lib/manticore/bitrix_catalog
    morphology      = stem_ru, stem_en
    min_word_len    = 2
    charset_table   = 0..9, A..Z->a..z, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
    min_prefix_len  = 3
}

min_prefix_len = 3 enables prefix search: user types "ноут" — finds "ноутбук". Use cautiously, increases index size.

PHP Client and Queries from Bitrix

Sphinx supports MySQL protocol, so it can be accessed via standard PDO:

$sphinx = new PDO('mysql:host=127.0.0.1;port=9306', '', '');

$stmt = $sphinx->prepare(
    "SELECT id, weight() as w, NAME
     FROM bitrix_catalog
     WHERE MATCH(:query) AND IBLOCK_ID = :iblock
     ORDER BY w DESC
     LIMIT :offset, :limit
     OPTION max_matches=1000"
);
$stmt->execute([
    ':query'  => $searchQuery,
    ':iblock' => CATALOG_IBLOCK_ID,
    ':offset' => ($page - 1) * $pageSize,
    ':limit'  => $pageSize,
]);

$ids = array_column($stmt->fetchAll(), 'id');

After getting the $ids array, load full product data via CIBlockElement::GetList() with ID filter. This is the standard pattern for search integrations in Bitrix.

Index Update

Sphinx supports two reindexing modes:

Full reindexing (indexer --all) — rebuilds index from scratch. For large catalogs, run at night via cron.

Delta index — indexes only changed records since last reindexing. Requires adding updated_at field to SQL query and separate source bitrix_catalog_delta:

source bitrix_catalog_delta : bitrix_catalog
{
    sql_query = \
        SELECT e.ID, ... \
        FROM b_iblock_element e \
        WHERE UNIX_TIMESTAMP(e.TIMESTAMP_X) > (SELECT max_doc_date FROM sph_counter WHERE id=1)
}

Delta index is merged with main via indexer --merge bitrix_catalog bitrix_catalog_delta.

When to Choose Sphinx over Elasticsearch

Sphinx is simpler to install (one binary, text config) and consumes less memory. Choose Sphinx if: limited server resources (< 4 GB RAM), data only from MySQL, no need for horizontal scalability. Elasticsearch is preferable with multiple data sources, cluster configuration, and real-time aggregation requirements.

Implementation Timeline