Ты ещё проверь что перестроение индексов не тормозит

А всё крутится на одной тачке или их несколько?

Подозреваю, что тоже тормозит

Там нет перестроения индексов. Там же btree. Индексы влияют при вставке безусловно, особенно, когда их 10 штук, но они не перестраиваются.

Одна тачка с raid1

Тогда тут только напалм

Имелось в виду создание новых индексов, я так понял

Можно сделать мастер-слейв. Делать поиск по слейву и тогда не будет конфликтов с записью. Но на одной тачке тут не помочь

перестройка старых, как я понял)

На слейв тоже будет нагрузка, он же с мастера изменения будет принимать

Но это уменьшит общую нагрузку по чтению

В любом случае, это без лишних усилий даст хоть какую то оптимизацию

У нас sphinxsearch стоит на hdd, и нет проблем с реиндексацией. Но опять таки. Там ему ничего не мешает. Нет активной работы с диском. Они там с redis вдвоём живут)

Про "бесконечную глубину". Если у вас данные (предложения) не ограничены по сроку жизни, то поиск надо будет делать по всем данным - на бесконечную глубину.
В качестве альтернативы можно ограничить срок жизни предложения, партиционировать таблицу по дате и искать только на определённый срок, глубже которого предложений точно не будет. В этом случае эффективность БД возрастёт.

понял, спасибо! да, данные сейчас не ограничены по сроку

P.S. Партиционирование тут нужно не собственно, как мера оптимизации, а как мера для управляемости базы. В частности, старые и совсем неактуальные партиции можно будет грохать. Но - в этом случае (если удалять старое) нужно избавиться от автоинкрементных и прочих "сквозных" ключей - например, использовать UUID со всеми сопутствующими мерами предосторожности от их коллизий.

Ужас, непроизводительно

Да, я понял идею, хорошая идея таким данным сделать срок годности, и чтобы они как-то сами удалялись, подумаю над этим

Claire Ward

Claire Ward

этот человек, насколько я понимаю, закинул в неизвестный мне чат.
и я вот смотрю, среди участников оказался 1 участник этого чата

поэтому, заблокируйте вот этого персонажа :)

Jul  5 18:14:36 nuclight daemon: DBD::SQLite::st execute failed: UNIQUE constraint failed: zytempdata.time at /home/vadim/work/zyTempSQL.pl line 77.
Jul  5 18:14:36 nuclight syslogd: last message repeated 1 times
Jul  5 18:14:36 nuclight daemon: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::SQLite::db handle /home/vadim/zytemp.sqlite at /home/vadim/work/zyTempSQL.pl line 77.

а почему такое странное сообщение? в этот момент было переполнение файловой системы