initial commit

public/uk/manticore-as-primary-database-usage-issues.gmi

@@ -0,0 +1,107 @@
+# Незручні моменти в роботі Manticore як основної БД
+
+В роботі з Manticore, є деякі моменти, які можуть відверто вибісити особливо тих, хто планує повний перехід з класичних баз даних типу MySQL та використання її, як основної бази даних.
+
+## Відсутність нормалізації даних
+
+Перше, з чим може зіткнутись користувач реляційних баз даних, який вирішив зберігати усі дані в Manticore - неможливість розбити дані по таблицям таким чином, щоб збудувати їх подальші нормалізовані зв'язки по зовнішнім ключам.
+
+Здебільшого вся база конкретного проєкту буде зберігатись в одній таблиці і варто бути готовим сприймати цю базу як по-рядкове сховище "key/value".
+А всі дані в ній - простий масив індексів.
+
+Тому на етапі проєктування, можна забути про UML, та MySQL Workbench - логіка бази даних в результаті буде повністю відрізнятись від класичної моделі зберігання SQL.
+
+## Вибірка тексту
+
+В Manticore / SphinxQL неможливо просто зробити чітку вибірку тексту, таку як:
+
+```
+SELECT * FROM table WHERE field = 'value'
+```
+
+Якщо потрібно фільтрувати рядки по тексту, потрібно спочатку створити числовий атрибут, наприклад хеш CRC32 і фільтрувати по ньому. Інакше запит завершиться помилкою.
+
+## Вибірка підрядка
+
+Можливо, є сторонні рушії, але стандартно ви не зможете наприклад додавати записи по умові PHP "strpos" та потім зробити таку само вибірку підрядка назад:
+
+```
+SELECT * FROM table WHERE MATCH ('@field "*alu*"')
+```
+
+До того ж, результат такої вибірки залежатиме від налаштувань "min_word_len" і "min_prefix_len".
+
+Обходити цю проблему доводиться в циклі пошукових результатів, з додатковою перевіркою "strpos".
+
+## Спеціальні символи SphinxQL
+
+Наприклад, на стадії індексації, ви заігнорили URL з символами "#" (якорі), "?" (динамічні параметри) через умову PHP.
+
+При спробі видалити такі старі записи в індексах запитом:
+
+```
+DELETE FROM table WHERE MATCH ('@url "#"')
+```
+
+- сервер видалить будь який URL, оскільки у цьому випадку "#" буде вважатись порожньою строкою "''" :)
+
+## Операції UPDATE
+
+Якось з'явилась ідея оптимізувати об'єм бази, перенесенням одного з полів CRC32 в індексну колонку "ID".
+
+Зробити це типовою командою SQL не вдалось:
+
+```
+UPDATE table SET id = crc32field;
+```
+
+Наступною спробою, була попередня вибірка і обробка скриптом в циклі результатів, але звісно, рушій не дав того зробити, тому довелось створювати індексну таблицю повторно.
+
+## Лімітування результатів
+
+Стандартно рушій лімітує вибірку до 1000 рядків, це не завжди зручно і потрібно додавати атрибут "cutoff".
+
+## Містика пагінації
+
+Приклад вибірки на одному з проєктів з використанням manticoresearch-php:
+
+=> https://github.com/manticoresoftware/manticoresearch-php
+
+```
+echo $index->search('')->maxMatches(10000)->offset(1000)->limit(1000)->get()->getTotal();
+> 5000
+```
+
+## Журналювання SELECT
+
+Наприклад у вашому скрипті пошуку інтернет сторінок, використовується перевірка наявності поля по його URL, таким чином, відбуваються мільйони перевірок і всі вони потрапляють до "query.log" як пошукові запити користувача.
+
+Це неймовірний треш, рішення якого так і не знайшов.
+
+## Стандартна стратегія Binlog
+
+Користувачі серверів з нестабільним підключенням до мережі живлення, можуть зіткнутись з проблемою крашу "binlog", після чого сервіс Manticore просто не стартує при завантаженні системи.
+
+Вирішується спочатку це видаленням "/var/lib/manticore/binlog/*" і ручним рестартом сервісу.
+
+Коли проблема набридає, виявляється, що стандартно Manticore зберігає транзакції по-секундно, замість збереження після кожної транзакції:
+
+=> https://manual.manticoresearch.com/Logging/Binary_logging#Binary-flushing-strategies
+
+Можливо, щоб зробити маркетинговий ефект швидкості в роботі, але по факту доставить вам мороки в пошуках причини.
+
+До того ж ця проблема є причиною "загадкових зникнень" деяких записів з бази (бо власне ви отримали server fault та скинули журнал відновлення "binlog")
+
+## Інше
+
+Відсутність більшості вбудованих функцій, типових для серверів SQL, можливість комбінованих запитів JOIN та інше - все це знайома ситуація, але на замітку.
+
+Будьте готові до емуляції SQL а не повної заміни.
+
+Створення проєкту на базі Manticore у якості основної бази - виправдано тільки для пошукових систем з великим об'ємом тимчасових даних, які перш за все не потребують чіткої вибірки, де MySQL є тягарем.
+
+Можливо будуть додані рішення, якщо такі будуть знайдені.
+
+## Дивіться також
+
+=> manticore-as-modern-alternative-to-sphinx-search.gmi Manticore як сучасна альтернатива Sphinx