Сейчас так и сделаю :)

https://github.com/cockroachdb/cockroach

Я советую сюда посмотреть

У меня сомнения только по производительности

Но доменную область опишите

Необходимо хранить отношения закладок пользователей (кто кого добавил в закладки). Отношение имеет вид: initiator_id;target_id. Два пользователя могут добавить друг друга в закладки. Действия над данными: проверка существования отношения exists(initiator_id; target_id), добавление закладки: insert(initiator_id; target_id), загрузка списка закладок по инициатору и удаление закладки. Предполагается, что один пользователь может добавить от 0 до 20000 других пользователь в закладки. Чаще всего будут проверки exists и добавления. Отношений могут быть миллиарды, поэтому нужно быстро добавлять новые ноды с минимальной конфигурацией после добавления

У вас что, сейчас миллионы пользователей?

Допустим, что да

Тогда как вы самих пользователей храните?

Имя и id, который автоинкремент

Если у вас реляционная модель, то в ней и работайте

И миллиард записей постгрес вытянет

Если уж вас приспичило на маштабуруемость, то думайте о дата локалити

Сейчас не очень, если честно

Пользователь должен как можно ближе лежать к своим закладкам

Особенно когда происходим автовакуум

Так делиты и апдейты частые?

лучше хранить списками

Insert частые

я копию вконтакта храню так, без всяких массивов - запросы довольно больно делать

Но в текущей реализации есть и update, в новой не будет

Только индекс у этим данных занимает 16 гб

Сами данные ещё около 10

Попробуйте cockrouchdb

А, кстати

Есть же citus

Туда же перетаскивайте пользователей и будет счастье

Попробуйте cockrouchdb

Спасибо, почитаю

Мы пробовали его использовать, но потом все же на кассандру перешли

Спасибо, почитаю

Лучше второе. Оно попроще

Насколько безопасны с точки зрения транзакционности удаления в Casandra?

так все-таки можно eventual consistency или нет?

так все-таки можно eventual consistency или нет?

Можно

Там вроде можно указывать уровень согласованности для каждого конкретного действия

это просто кворум, он вообще ничего не значит кроме того, что запись останется при падении N нод

Можно

тогда вопрос про транзакции должен сам сняться

Я тогда просто спросил для общего развития :)

Спасибо всем на советы и идеи

Я тогда просто спросил для общего развития :)

Может не актуально, но есть ещё вот такое решение - https://clickhouse.yandex

Может не актуально, но есть ещё вот такое решение - https://clickhouse.yandex

Актуально, спасибо!

Там нет апдейта

Так а разве это кто-кого доставил в закладки...

Очень похоже на друзьяшек

Может тогда посмотреть в сторону графовых БД?

Коллеги, добрый вечер. Где-то, помнится, была ссылка, пригодная для давания принимающим решение товарищам, с описанием преимуществ postgresql

В контексте импортозамещения и не только

Не подскажете? Не могу навскидку найти

Собрались замещать импортное на импорт?

</politic>

Хочется найти текст с рекомендациями приводящими к выбору pgsql. Postgres Advocacy, в общем

преимущество - величина относительная, а не абсолютная

Опять надо Сашу Короткова

Коллеги, добрый вечер. Где-то, помнится, была ссылка, пригодная для давания принимающим решение товарищам, с описанием преимуществ postgresql

На Хабре полно холиваров пострес против мускуля

Это не совсем то — это о технологии, а нужны правильные слова не для программера, а для директора

@aekorotkov

Саша, нужен чек лист фичей

Для выбора postgres а

Против остального

Это не совсем то — это о технологии, а нужны правильные слова не для программера, а для директора

The world's most advansed opwb source database

Коротковато. Не поймут-с ?

Пока вот такое гляньте

https://www.postgresql.org/about/featurematrix/

Там нужно про сравнимость функциональности, но наличие сильной отечественной школы, коммерческой поддержки в РФ, сертифицированности, совместимости с Astra, etc, etc

Да, Михаил, спасибо, это хорошая инфа, но не совсем то ? Вы же, скажем, министру это не будете показывать? ?

Я буду например

Это

Ок, но он не оценит, мне кажется.

Ну в Росреестре есть postgrespro

Тогда надо внутри реестр бенчить

Ну в Росреестре есть postgrespro

А что там на нем?

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

В реестре отечественного ПО

Я про это

Ааа

Просто в Росреестре - oracle )

А министр приезжал кстати на тусовку postgres в Москве

Он в теме

Ну текущий министр

Не факт что он будущий

Необходимо хранить отношения закладок пользователей (кто кого добавил в закладки). Отношение имеет вид: initiator_id;target_id. Два пользователя могут добавить друг друга в закладки. Действия над данными: проверка существования отношения exists(initiator_id; target_id), добавление закладки: insert(initiator_id; target_id), загрузка списка закладок по инициатору и удаление закладки. Предполагается, что один пользователь может добавить от 0 до 20000 других пользователь в закладки. Чаще всего будут проверки exists и добавления. Отношений могут быть миллиарды, поэтому нужно быстро добавлять новые ноды с минимальной конфигурацией после добавления

Можно в редисе хранить в структуре set

http://www.sql-workbench.net/dbms_comparison.html

Можно в редисе хранить в структуре set

Он же не совсем база данных. Данные, кстати, теоретически могут потом не поместиться целиком в память.

Но такие штуки грешат неточностями

@aggeisoft ^

Он же не совсем база данных. Данные, кстати, теоретически могут потом не поместиться целиком в память.

Для этого расшардировать по серверам, да. Каждый сервер может довольно много множеств хранить, думаю.

Миллион так спокойно

Но такие штуки грешат неточностями

Да - заметил неточности

Саше Короткову написал

вконтакт свою базу написал, https://github.com/vk-com/kphp-kdb/blob/master/docs/ru/DBMS_Storage_Comparison.wiki

Глянет скорее всего сюда

Я точно знаю что у них есть такое

Но мне уже самому лень щас искать/гуглить

вконтакт свою базу написал, https://github.com/vk-com/kphp-kdb/blob/master/docs/ru/DBMS_Storage_Comparison.wiki

там набор движков и почти что совсем нет доков

с самим kphp еще туда-сюда (хотя тоже не айс без доков), а с движками - вообще ... короч не для нубов типу меня

куча неочевидностей и все методом тыка находить.. к примеру булевые and/or там не поддерживаются, только &&/|| , только хардкор

Можно в редисе хранить в структуре set

Please, no. Хотя, будет не хуже, чем в постгре.

По времени выборок и вставок вкупе с оверхедом - значительно значительно лучше

Оверхед на больших множествах в редисе - будь здоров.

Но, учитывая, что большинство множеств маленькие, наверное жить можно.

Ну 20000 элементов не так уж много

Есть порог "маленького множества". Пока число элементов меньше порога, оверхед по памяти маленький. Как только переваливает за порог, оверхед становится огромным.