Привет, работал кто-нибудь с badger или другими key-value хранилищами? Написал

воркера, который постоянно держит базу открытой и обновляет в ней строки. Ну там около 100млн. строк. А когда до меня дошло что второй воркер не может достучаться до базы данных чтобы читать строки, так как ее постоянно юзает первый воркер, расстроился и весь мой план провалился.

Можно как-то организовать хранилище key-value с 100млн+ строками, чтобы две программы могли работать с одной базой? один постоянно только читает, второй обновляет\пишет\удаляет то что есть в БД.

бери etcd, там это ещё и распределённо можно делать и вообще всё что захочется с kv

100 млн ключей в etcd, сильно

бери нормальную бд типа монги

"монга" и "нормальная бд")

с другой стороный не могу назвать бд которая не дает подключиться более 100 клиентам и ей требуются костыли нормальной *пошел за попкорном*

возьмите redis, самое то судя по требованиям - key value со всякими плюшками сверху

А что за база не позволяет работать с двух воркеров?

это ембед

badger. https://github.com/dgraph-io/badger возможно я просто что-то не так готовлю\применяю. Не спец, пишу как могу, не стреляйте)

слишком много для инмемори

+ именно. сервер у меня обычный 16гб RAM и на нем я всё не умещу в память

100кк key value пар? это вообще то копейки

100млн в инмемори, что то на богатом

Я тут подумал что первый же воркер может просто поднять у себя простую апи и по ней может стучаться второй воркер и получать данные? Тогда вообще база всегда одна и никаких лишних копирований. Может это правильное решение?

тогда можно какую нибудь постгрю, она поддерживает jsonb и вообще шикарно работает на малом количестве ресурсов

вы пытаетесь написать свою бд по сути, не стоит так делать без веской причины

можно свой сервер навернуть вокруг встраиваемой базы и чтобы компоненты приложения обращались к этому серверу по сети, например. по-моему вы просто пришли к тому, что вам не подходит встраиваемая БД.

Да не. У меня просто воркер2 должен знать сколько денег на счету АААБББ. Ну примерно) И у воркера2 есть своя база на PG и он вообще там много чем занимается. Но я запилил воркер1, который постоянно обновляет 100млн строк и хранит это дело в Key-Value badger базе. Ну и сначала подумал что надо как-то это дело перекидывать в базу PG. Или воркером2 открывать Key-Value базу. Но это как миниум перемещение > 5Gb данных по сети, что не очень то хорошо. Теперь мне вот мысль с поднятием API сервера на воркере1 все больше и больше нравится

Я во встраиваемую БД пришел, т.к. у меня сервер обычный HP microserver Gen8 с 16Гб ОЗУ и 4ТБ места. А работать хочется быстро и эффективно на выборках в 100млн строк. И ни PG, ни монгу я настроить нормально не смог ни на загрузку таких данных, ни выборку по ним в адекватное время. А тут kv меня прям удивила скоростью. Просто логики не хватает мне как организовать общение воркеров правильное.

А в ПГ индексы создавали?

ну отчасти встраиваемая бд и быстрее тк это просто папка с файлами, залоченная конкретным процессом. а такие вещи, как сетевые коннекты и конкуррентные пользователи или фоновые операции они там не поддержаны. как я выше уже написал со встраиваемой бд можно сделать синглтон-логику. те какой 1 процесс открывает базу и работает с ней. а дальше другие компоненты связываются с ним по сети, например gRPC. можно еще оставить 1 процесс и наплодить горутин, раз у вас 1 сервер, то и горизонтальное масштабирование вам не придется втаскивать - не пробовали так?

Конечно! ПГ у меня на таких объемах работает еще сносно. Но как подходим к 500млн строк, так совсем всё печально становилось с выборками. Теперь даже не знаю когда снова рискну работать с пг)

Вот именно то что и хочется попробовать теперь.

если у вас второй воркер это всего-лишь горутина внутри того же процесса, то этот второй воркер без труда переиспользует коннект к бд

Не, это две разные программы самостоятельные.

а зачем они самостоятельные, если сервер всего 1 и это не изменится?

Так один это сервер, который обслуживает пользователей. Бэкенд для web, android, ios клиентов. И просто иногда этому бэкенду надо знать балансы о неких "счетах". Вот тогда-то он и должен обращаться к чему-то готовому и мгновенно получать эту информацию. Вот для него и написан второй воркер, который много чего делает и в итоге укладывает готовые данные пачкой в KV хранилище у себя. И встраивать функционал одного в другого - это может быть сильно больно, т.к. тот что укладывает в KV хранилище очень сильно использует ресурсы и скорее всего уедет на более мощный сервер в будущем для того чтобы готовить данные быстрее.

Clickhouse попробуйте от Яндекса. У меня на ней DPI анализатор крутиться в одном из проектов .

С какой пропускной способностью 🤔

Спасибо. Идеальное решение оказалось. Всё работает как часики. И 100млн спокойно помещаются дважды в 16гб памяти, что позволяет производить все необходимые операции. И скорость. Прям впечатлил redis.

только не допускайте утилизации памяти/процессора выше 30% на редисе - иначе он вас сильно огорчит

Благодарю за рекомендацию!👍 В некие таймауты уже успел воткнуться на flushdb при 70млн+ строках в базе. Но как ни крути это лучшее решение из всего что опробовано. А опробовал много.

ну вот еще аэроспайк можно попробовать. он кластерный, и именно таких проблем за ним не водится