Race Condition убил SQLite в нашем проекте: как мы пришли к RediSearch

[DennisP]

Естественно, ведь SQlite это библиотека, а не север, соответственно нет никаких продвинутых механизмов типа row-level locking. А есть тупо блокирование всего файла, т.е. БД на запись. Ниша SQlite другая.

[kmatveev]

Вам не приходила в голову идея переложить через очередь в один поток, который будет сохранять? На reactor-e, который является основой webflux, это должно занять примерно 20 символов кода

[KarimAbushaev]

Тогда теряется скорость записи, по факту тот же redis получается? Только он с этим справляется лучше

[Pcturl]

А вот опытные люди пишут, что он тоже не без нюансов:

[LeshaRB]

Промышленный сервис телеметрии. Данные от датчиков летят через WebSocket и REST. Слышал про Redis, но не применял. На выбор — SQLite или Redis, надо исследовать что лучше. Пошёл читать. Нашёл TimescaleDB и ещё кучу вариантов — у каждого свои плюсы.

Так с постгресом, что не так! Чего его использовать нельзя?

[Ktulhy]

«Зумеры обнаружили, что sqlite однопоточный». Каждый раз. Без суеты. Твёрдо. Чётко. Ты «вскрыл» самую суть.

[EgorSharin]

У меня накопился немалый опыт работы с timeseries databases. Поэтому тем, кто это будет читать, если вам особенно важна скорость многопоточной записи, советую присмотреться к QuestDB и ScyllaDB.

Помимо записи, QuestDB - в первую очередь, аналитическая база данных, и когда впервые запускаешь аналитическую query на примерно сотне миллионов строчек (каждая - 9 столбцов, на 4-х из них - или WHERE, или GROUP BY), с непривычки скорость выполнения запроса заставляет предположить, что я где-то лоханулся, и это - не настоящий результат, а какая-то фигня: безумно быстро (после многих лет работы с SQL Server и PostgreSQL). Очень рекомендую.

ScyllaDB попроще и немножко “поглупее”, - никак не аналитика, но зато multi-master replication в бесплатной (!) версии. И оно реально работает.

Я уже год как ушёл от PostgreSQL, и не жалею.

[boldape]

В скулайте просто задайте свой хук обработчик бизи который бесконечно ретраит и ни одно сообщение не потеряется. Скулайт прекрасен вы его не доготовили.

[inilim]

Есть куча мест для оптимизаций, например добавлять записи через json функции, это обеспечивает быстрое добавление в бд. (Чем быстрее вставка чем меньше блокировок) Этот трюк улучшает не только добавление но и выборку и обновление.

db.execute("""
WITH data AS (SELECT e ->> 'name' as name, e ->> 'email' as email FROM json_each(?) e)
INSERT INTO users(name, email) SELECT data.name, data.email FROM data
""", [jsonEncode(data)]);

Еще можно создавать базу in-memory, вставлять ограниченное количество записей туда, и при достижении максимума, через присоединение БД (ATTACH), переносить строки в файл и очищать in-memory бд.

ATTACH DATABASE file_name AS database_name;

На крайний случай, создавать временные файлы бд которые дублируют структуру таблицы с которой работаете, и через время импортировать в основную базу.

[diafour]

Вот тогда я и понял что выбирал не по тем критериям.

В общем да, скорости многопоточной записи и возможности "поиска датчика sql запросом" как будто мало для выбора бд к "промышленной телеметрии".

Вы же данные не просто собираете, надо их будет анализировать как-то? Prometheus (и аналоги victoria, prompp), influx, clickhouse, упомянутый вами же timescaleDB на основе postgres — у них всех из коробки есть аналитические функции. Дальше нужно будет строить графики, тут пригодятся функции для работы с интервалами, группировки с округлением времени, rate/irate/rate с поддержкой отсутствующих значений.

А ещё ha режим, бэкапы, шардирование, агрегация данных увеличенным интервалом для истории, алерты и наверняка что-то ещё забыл.

С sqlite это всё нужно будет писать самому.

P.S. Признаюсь, я и сам использовал sqlite для хранения таймсерий (и оно живёт в продах), но это было промежуточное хранение значений, чтобы дальше отдать в prometheus.