Миллион алых нод: о выборе баз данных для хранения больших объёмов

Алексей Рыбак. Ребят, сегодня в гостях у нас замечательный гость Костя Осипов. Кратко его представлю. Костя проработал, наверное, лет двадцать пять в разных компаниях, начиная с продуктовых, типа Спайлога, потом работал в MySQL, потом работал очень долго над Tarantool, сначала в Mail.ru, потом в VK, потом работал директором по разработке в Сцилле (ScyllaDB). Это такая сумасшедшая, быстрая, большая, база данных. Сейчас развивает в группе компаний ArenaData – Piсodata – собственную базу данных, которая построена поверх измененного движка, как я понимаю, Тарантула. 

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

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

Дело было довольно давно, работал я в компании Badoo. Badoo/Bumble - это такой конкурент Tinder. Сейчас в целом этот рынок немножко схлопывается, но, по моему, и там, и там по полмиллиарда юзеров, большие базы данных, всю переписку хранят где-то на своих серверах. И вот мы хранили всю переписку пользователей в MySQL. У нас была собственная шардированная инфраструктура. В свое время Петя Зайцев нам объявил, что у нас самая большая инсталляция MySQL в Европе. Вот и мы продолжали долгое время этим гордиться. Хотя, в общем, не очень понятно, чем гордиться. Что с Европой сравнивать? Надо с Америкой сравнивать. А там, конечно, такие гиганты, с которыми сравниться тяжело. 

В общем, хранили мы там переписку. Транзакционно все там было: и папки, и новые сообщения, и вот это вот все. И постоянно, естественно, битые денормализованные счетчики, как водится, которые не только у нас, они и у ВК есть и были, у Фейсбука, у Телеграма время от времени даже появляются такие баги – непрочитанные сообщения, и хрен знает, как его сбросить, оно просто вот не сбрасывается. Вот. В общем, короче говоря, вот столько, столько вот этого барахла мы огребли, и я бы сейчас не хранил это в базе данных MySQL точно, может быть, хранил в Postgres, но как будто бы из того, что я знаю про Postgres, то тоже бы там не хранил. 

Вот скажи, пожалуйста, Костя, вот если стоит такая задача - большой проект, надо хранить переписку, очень много, может быть, комментариев, сообщений. Почему классические базы данных, к которым мы привыкли, не очень хорошие, может быть, Postgres почему здесь не очень подошел? И какую бы базу данных ты рекомендовал? 

Константин Осипов. Слушай, я не знал, что вы хранили в MySQL. Я бы не стал прям так говорить, что это полная ерунда, потому что Facebook тоже хранит переписку в MySQL (Meta Platforms Inc., владелец Facebook — организация признана экстремистской, её деятельность запрещена на территории РФ). И мой кореш работал там долгое время и занимался автопровижинингом. Он мне в какой-то момент говорил, что у них миллион инстансов MySQL. Он отвечал за весь этот флот. Там все было на контейнерах, все было на автоматизации полностью сделано. Ну, потому что по-другому просто никак. И он писал этот программный код, который оптимизировал все это шардирование ручное. То есть, хранение переписки - это частная задача, так как переписка шардируется по паре абонент-абонент. И, соответственно, все назначения пользователей на шарды, можно более менее статически делать. Где-то держать отдельную базульку, в которой все карта шардирования хранится. И эта базулька уже становится таким сакральным местом, в которое ходит вся организация. 

Но Discord хранит свои сообщения в ScyllaDB, это тоже факт. Это один из крупнейших кейсов – там объем данных исчисляется в петабайтах. Поэтому однозначно сказать что Badoo делал неправильно нельзя, и я бы твой вопрос, где хранить, разложил на две составляющие. 

Первое - это насколько ты хочешь заморачиваться с ручным шардингом. ScyllaDB, Cassandra, позволят тебе забыть про ручное шардирование, позволят добавлять, удалять узлы, то есть наращивать этот кластер с помощью средств СУБД. И это большой профит. 

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

Есть TiDB и CockroachDB, которые позиционируют себя как горизонтально масштабируемые, но я  честно скажу, их сам не готовил. И не видел каких-то больших историй успеха. Хотя я знаю, что у TiDB дела идут неплохо. Yugabyte, третья база из этой когорты, тоже у нее дела идут как-то. Но при выборе между Cassandra/ScyllaDB и остальными в их пользу срабатывает фактор масштаба - они уже воспринимаются сообществом как too big to fail. Cassandra вообще входит в топ десять баз мира по популярности. 

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

Алексей Рыбак. Прости, пожалуйста, можно я тебя перебью? Ты не назвал MongoDB. Mongo в свое время пиарилась как раз такой возможностью. Но ты говорил про то, что даже по вашим тестам добавляешь новые ноды и происходит что-то не очень хорошее. Здесь можешь развернуть, почему не Mongo? 

Константин Осипов. Наши тесты были про транзакционную нагрузку. То есть, действительно, транзакционная нагрузка в Mongo по нашим тестам замедлялась при добавлении узлов. Если нагрузка шардируемая, то есть транзакция попадает на один реплика-сет, то распределенных транзакций Mongo не будет, и можно ослабить Write Concern и скорость будет выше, и с масштабированием будет всё лучше. 

Но давай так: в моей голове Mongo ушла в Atlas и как on-premise база существовать перестала. Может быть, я не прав, но, на мой взгляд, текущие лицензионные ограничение исключают её из рассмотрения. Хотя я знаю, что и в России до сих пор есть достаточно большие инсталляции Mongo, но об их лицензионной чистоте говорить не буду. Если расширять этот список, я бы смотрел в первую очередь ClickHouse, и  разбирался с тем почему он меньше подходит для этой задачи. 

То есть, в Mongo можно, особенно если это managed Mongo, запихнуть большой объем данных. Но в основном я вижу что к Mongo приходят, если нужен JSON, причём не просто хранение, но и индексация. Это история с постоянно мутирующей схема данных. Для сообщений – это оверкилл, на мой взгляд. При хранении сообщений, схема достаточно линейная, есть какие-то атрибуты сообщений, да,могут появляться новые атрибуты, но это не требует JSONсхемы. Все представляется парой таблиц. 

Поэтому я не подумал про Mongo вообще. Знаешь, сейчас эта история с лицензиями очень запутывает. Раньше ты мог просто говорить на все - open source. Сейчас нужно делать оговорки. На сегодня, например ScyllaDB, практически ушла из комьюнити сегмента. В конце 2025 они ввели ограничение, что бесплатную версию можно использовать только до 10ТБ и 50 ядер и это лимит на всю организацию. Ты можешь, конечно, взять и нарушить это, но если ты выбираешь базу вот просто с нуля, зачем тебе с этим связываться?

Поэтому действительно открытой сейчас остается только Cassandra. Cassandra изначально была таким мальчиком для битья у Scylla, потому что Cassandra писалась еще под под SATA диски и на SSD она, особо рекордов по скорости не ставила. 

Но в четвертой, пятой версии, особенно в пятой, сменили Java платформу, убрали узкие места. Пятая Cassandra уже бодренько себя чувствует по сравнению с ScyllaDB на SSD дисках, не так сильно проигрывает ей по скорости. Если раньше отставание было в пять-шесть раз, то есть  можно было найти кейсы, когда Cassandra в пять-шесть медленнее Scylla, то сейчас это полтора-два раза. И скорость для таких баз  далеко не всегда bottleneck, потому что у тебя просто все равно огромное количество хостов. 

Средний трафик, в пересчете на 1 хост не сравним с общим объемом данных на хостах. В таких инсталляциях основная боль - это огромное количество холодных данных, которые постоянно растут. Представь себе, ты хранишь данные 3 года. Значит через три года объём данных, которые ты удаляешь, сравним с объемом данных, которые ты вставляешь. У базы данных появляется "невидимый" трафик в виде удаления данных по TTL.

Поэтому не подумал ни про Mongo, ни про кого-то еще, хотя у Mongo есть и TTL. 

Так вот, первая размерность — это насколько база автоскейлится. Вторая размерность — это storage. Насколько storage хорош для такого рода данных. ScyllaDB, Cassandra — это LSM-дерево, с разными уже испытанными в сообществами стратегиями тюнинга этого LSM-дерева. 

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

И хотя шардирование придется сделать вручную, storage у MySQL достаточно предсказуемо будет работать на более-менее любой нагрузке. InnoDB справится и если в сутки один процент базы добавляется, и это подводит нас к PostgreSQL 

У Postgres со сборкой мусора как раз будут проблемы. Чем больше размер базы, тем дороже сборка мусора, как бы ты ни старался. Это беда вообще всех однопроходных сборщиков мусора. Для того, чтобы собрать один процент мусора, все равно нужно просмотреть все данные. Соответственно, данных становится больше – сборка становится дороже. 

Поэтому, собственно, Postgres для таких задач и не едет. Мало кто  в таком разрезе смотрит на эти вещи, но в конечном итоге срабатывают ограничения движка HEAP. 

Алексей Рыбак. Слушай, хочу быстренько выяснить. Вот у меня всегда в голове звучала эта цифра в терабайт, два терабайта. Понятно, что можно приготовить Postgres и на большее количество данных. Во многих облачных инсталляциях есть прямо внутренние policy, да, что типа ребят, давай там, не знаю, несколько терабайт. Это определяется, скорее, по-твоему, вот этой особенностью со сборкой мусора или, скорее, вопрос скорости восстановления в случае каких-нибудь аварий, переездов и так далее. Как ты считаешь?

Константин Осипов. По-моему, второе, потому что конкретно с теми людьми, с которыми общаюсь я, да, у них прям стоит четкий лимит, что восстановление из бэкапа должно занимать меньше четырех часов. А если ты используешь incremental backup, то восстановление у тебя может легко занимать на больших базах сутки. Поэтому, по моему, это больше про второе. Ну и, но опять же, понимаешь, если ты облачник, то ты должен подумать сразу про много что. 

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

И я думаю, что это верно для любых организаций, в которых этих Postgres будет не один и не два. Если у тебя их десять, двадцать штук хотя бы, то ты все равно хочешь какую-то типовую историю. Это первая причина. 

Вторая причина - это тебе нужно же как-то дифференцировать свои облачные продукты по цене. Если ты облачный провайдер, ты понимаешь четко, что клиент, у которого пять, десять терабайт – это клиент с деньгами. И ты не хочешь, чтобы СУБД на 10 терабайт стоила как 5 СУБД по 1 Терабайт. Ты хочешь поместить средний и малый бизнес в свой ценовой сегмент, а крупный в свой.

Думаю, что в облаках это основные два фактора. 

Расскажу в связи с этим, мне кажется, интересную историю. Приходит студент и хочет взять для дипломной работы какую-то тему по LSM-деревьям. Мы выделили какие-то темы. И так получилось, что я их закодил сам. Он вообще не растерялся. Говорит: "Слушай, я вот тут смотрел недавние работы научные ”. Ни фига себе, думаю я, какой-то настоящий студент. Смотрит научные работы, не то что я. Нашел исследование, как правильно делать удаление записей по TTL для LSM-деревьев. 

Это всё ещё большая проблема. Когда у тебя база хранит данные и удаление происходит по пользовательскому запросу, приходят delete, ты как-то их группируешь, удаляешь и так далее, это одно. А когда у тебя лежат холодные данные, но, в 12 ночи куранты пробили и, условно говоря, половина базы превратилась в тыкву. Как в этом случае эти данные эффективнее всего удалить?

У базы должен появиться какой-то внутренний планировщик, который умеет рассуждать в стиле: у меня через час TTL заэкспарится, мне надо будет данные все равно удалять, значит можно объединить процесс удаления с с другими процессами, например сборкой мусора.

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

Алексей Рыбак. Погоди, ну TTL – это какой-то сценарий персистентного кэша получается, потому что, ну вот мессенджер, мы все хранили. Не было удаления.

Константин Осипов. Но смотри, как бы,  было. Вы удаляли юзеров целиком, скорее всего, по неактивности. То есть у вас было наверняка период неактивности, после которого вы удаляли профиль, полгода или год. 

Алексей Рыбак. Не, было, кстати говоря, ну, стали внедрять, ну, в первые годы точно не было. Стал появляться GDPR довольно агрессивный. И вот вот здесь, скорее, мы коснулись этой темы до того, как стали думать, как оптимизировать. Понимаешь, это с точки зрения user experience довольно клево, если ты вообще его не трогаешь, не дергаешь, я время от времени получаю какие-то сообщения (о скором удалении всех данных из сервисов). А я вообще не понимаю, блин, это важно, неважно, они что-то удалят. Нахрена вы удаляете? То есть я к этому привык, но в целом, с точки зрения пользовательского опыта, это не очень здорово. Ну да, я на какое-то время был неактивен, а вы сразу меня удаляете. Первое время точно не удаляли. 

Константин Осипов. Хорошо. То есть ты хочешь сказать, что обычно это все равно продуктовым образом формулируемое условие, и у тебя в результате все равно удаление выполняет какая-то background задача. 

Я тебе про Кассандру ещё одну байку хочу рассказать. Прихожу я в одну очень, очень большую в масштабах страны организацию. 

Она хранит в Кассандре полтора петабайта данных трекинг документов. Там есть ID документа, откуда, куда, вот текущее состояние и так далее. У документа есть какой-то жизненный цикл, достаточно короткий а потом он хранится в архиве. Ну и разговоры выглядят так. "Ребят, вы зачем вообще сюда пришли? У нас все работает." Кассандра  справляется, только железо докидывай. 

Я что хочу сказать. На таких масштабах у клиента главными становятся  две боли. 

Первое – отойдите и не трогайте. Это основная, основная проблема любых крупных кластеров, ты сложил все яйца в одну корзину и потеря всего кластера означает крах организации. Поэтому мне нравится история с MySQL чисто психологически. Я знаю, как оно у меня устроено. Если оно у меня развалится, у меня потеряется лишь часть клиентов, но бизнес не прогорит. Если у меня какая-то крупная банка вся превращается в тыкву, это психологическая, очень неприятная история. 

Вторая история на таких больших банках – это то что шаг влево, шаг вправо, и ты начинаешь терять бабки. Ты долго и упорно тюнил все настройки для этой базы, включая компрессию, удаление данных, кэширование, в общем движок в целом. И если в какой-то момент ты не так затюнил у тебя тупо начинают расходы расти, потому что ты каждый месяц, или квартал, в эту базу подкидываешь железо. 

Это возвращает нас к вопросу о retention policy. В какой-то момент ты говоришь: хранить все. Если у тебя достаточно денег, если у тебя хорошая бизнес-модель для этих данных, то да, ты хранишь все. Если ты хранишь промышленные данные, технологические данные, трекинги — у телекомов CDR, так называемые call data records, — их тоже надо хранить. Каждый телефонный звонок генерирует CDR раз в пятнадцать секунд. Соответственно, количество этих данных только растет. И ты уже начинаешь думать: слушайте, дайте мне что-нибудь, что на три процента сэкономит мне бюджет хранения, и я буду экономить по сто, по двести тысяч долларов в год.

И это третья причина, по которой я на MongoDB не посмотрел. Место на диске необходимое в разных базах для хранения  одних и тех же данных разное. У кого-то менее эффективный формат представления данных, у кого-то компрессия хуже работает, у кого-то мусор дольше хранится. На масштабе это все влияет на бюджет. 

Алексей Рыбак. Хорошо. Если сейчас безотносительно лицензии у меня встает вопрос что выбрать.  За Scylla стоит какая-то организация, я могу прийти и получить от этой организации какие-то материалы, в том числе они мне скажут, что Discord на Scylla, еще какие-то проекты, да? А вот про Cassandra я как бы вижу ее в топе. Я могу спросить у наших маленьких AI-помощников: расскажи мне, что ты знаешь. Или по старинке поискать, но как будто не очень достоверная информация. Вот если просто взять, пытаться ответить на вопрос, например, по размеру инсталляции Scylla и Cassandra, как это можно было бы сравнить, насколько это вообще реально? 

Константин Осипов. Думаю, что у Cassandra дофига крупных инсталляций. Основные организации за Cassandra – это Netflix и Apple. У Netflix в свое время в Cassandra сидела вся история взаимоотношений клиента с платформой. 

У Apple до сих пор в Cassandra сидит  куча статистики. У тебя есть parental control, да? Ты заходишь и смотришь, что мой ребенок делал. Вот это тоже сидит в Cassandra. Это достоверно достаточно. 

Apple – один из крупнейших contributors в Cassandra. Команда из Apple сделала транзакции в Cassandra 5. Это были не ребята из DataStax. 

Кстати о DataStax, уверен, если придёшь к ним, они тебе что-нибудь расскажут про крупнейшие on-premise deployment. Но что глобально поменялось у всех вендоров, включая даже MySQL, и, кроме самых старых, типа EDB, или MariaDB, это то, что они все позиционируют себя как cloud-вендоры, и вкладывают основные ресурсы в развитие cloud версий.

Даже в случае ClickHouse, который изначально создавался Яндексом как on-prem, сейчас все больше фич про cloud. Тот же Neon, который купил Databricks, это тоже про cloud. 

Алексей Рыбак. Ты упомянул про какую-то интеграцию или плагин у Пикодаты. Но давай немножко, может быть, здесь тоже со стороны даже не трендов, а каких-то мест баз данных. PicoData — это такой облагороженный Tarantool для меня, по крайней мере, да? Вот то, что я читаю: SQL интерфейс, удобное управление нодами в кластере и так далее. А я так понимаю, что это в целом все равно класс баз данных, где у тебя все должно поместиться в память. 

Константин Осипов. Нет, нет, смотри, как это “все”? У Пикодаты история такая, что, вот как бы мы делали Tarantool. Tarantool имел определенную нишу, как in-memory application сервер с кучей скриптования, где тебе нужно какую-то логику иметь в базе. И в какой-то момент наступила развилка, что с этим дальше делать? И Пикодата стала делать базу данных общего назначения. Вот прям просто распределенную базу данных. Взяли Tarantool как движок и стали делать из него кластерную СУБД. По этому пути мы идем. 

А дальше встает вопрос: а где деньги? Вот в России деньги сейчас в критической инфраструктуре, в импортозамещении. То есть, условно говоря, есть 187-ФЗ, который говорит, что организации, которые имеют так называемую критическую инфраструктуру, и определяет, что это такое, сколько там пользователей у них, там, в масштабах страны, какие данные хранятся и так далее, они должны использовать отечественные СУБД. Мы изначально сделали Postgres-frontend, который просто делает такой вот “резиновый Postgres”. 

Он ограничен по фичам, но он масштабируется горизонтально. И это закрыло ряд кейсов. Потом мы сделали то же самое для Redis, то есть сделали Redis-кластер. Если Postgres итерфейс у нас опенсорсный, под BSD-лицензией, то Redis - чисто проприетарная фишка. 

Сделали, тоже внедрились, здесь тоже понятный профит. Скорость довольно высокая. Мы сейчас последний релиз бенчили, он практически по скорости от Redis не отличается. Там Valkey куда-то ушел, но это не принципиально. Все равно  если у тебя кластер, у тебя в основном ограничение по размеру, а не по скорости. 

Итак, сделали Redis. А у Tarantool был Vinyl как движок для дискового хранения.  И последние полгода я сильно допиливал его до конкуретноспособных показателей. И вот сейчас мы сделали Cassandra, как третий  frontend.. Людям нужно, нужна коммерческая поддержка, нужно импортозамещать Cassandra. Но мы там много чего интересного докрутили. Словарную компрессию, которая только в шестой Cassandra появится, у нас уже есть. Сборка мусора у нас также устроена  совсем по-другому, мусор удаляется и это работает студенческой  работы,о которой я рассказал. 

Но когда ты как разработчик, и у тебя как у разработчика стоит вопрос выбора баз – скорее всего ты не выберешь Пикодату. Потому что ты будешь выбирать то, что использует твой сосед. 

А Пикодата выбирает уже какой-нибудь там CIO (Chief Information Officer), даже CISO (Chief Information Security Officer). Приходят юристы, безопасники  и говорят, что Cassandra больше использовать нельзя. Все, что ты будешь делать? 

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

А вообще, если посмотреть на Пикодату как на обычную горизонтально масштабируемую СУБД,  у нас уже сделан полноценный SQL с JOIN'ами, оконными функциями. И он уже больше подходит для параллельной аналитики, что-то вроде Clickhosue или Greenplum, который держит сотни и тысячи одновременных сессий. 

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

Алексей Рыбак.  Я правильно понимаю, что в целом Пикодата уже ушли от ограничения, которое, как я понимаю, до сих пор есть у Tarantoola, что все, все данные должны помещаться в памяти? И в этом смысле сейчас я подчеркну, я вообще довольно люблю Redis, слежу за тем, что делают там Amazon, Valkey, ну, Amazon и остальные cloud провайдеры с Valkey. Вот это ограничение, оно на самом деле фиговое, потому что оно не дает возможности использовать этот продукт для большого количества сценариев. Я правильно понимаю, что фактически вы с этим плагином можете взять и сказать: у нас будет свой движок, это своя база данных, совершенно не обязательно все должно попасть в память, а наружу оно будет работать как Redis. Или я что-то неправильно понял? 

Константин Осипов.  Ты правильно понял. Redis интерфейс поверх дискового движка это прям  фича одного из ближайших майлстоунов. Оказалось у людей, которые пользуются Redis, есть два основных сценария.

Первые, и таких большинство, они отключают append only file и  используют Redis без кластера, фактически режиме memcache. То есть без персистентности, без репликации и так далее.  Мы поддерживаим этот сценарий в первую очередь, хотя в нашем случае это все равно будет кластер, и данные редиса всё равно будут храниться в таблицах СУБД. Если тебе не нужна репликация, не нужен HA (high availability), окей. 

Вторая история – это тебе уже все-таки хочется in memory, но с дисковым бэкэндом.  Чтобы не было проблемы холодного кэша после рестарта? То есть до какой-то группы людей доходит, что я лучше все таки буду писать кэш на диск периодически, чем думать что делать при рестарте или потере данных в кэше.. 

А третий кейс, про который ты уже говоришь, это типа чуваки, да, я хочу, ну, вообще резиновый Redis. SSD сейчас быстрые, просто мне нужен нормальный кэш. Помнишь, был Varnish в свое время? Varnish-кэш. Вот ты хочешь что-то типа Varnish – мы такой кэш подвезем тоже. 

И ты прав, что сам подход, что ты строишь эту историю поверх СУБД, он лучше. Вообще в СУБД такое количество избыточности, если честно. Сообществу действительно не нужно такое количество вендоров. Про Пикодату тоже так же можно наверное было бы сказать,  что вы делаете, ребята? 

Алексей Рыбак.  Cлушай, а какой в какой момент Picodata перестала быть такой резидентной базой? Бог с ним, с Redis. Мне казалось, что в целом вы повторяете вот этот паттерн тарантуловский. 

Константин Осипов.  Я ещё год назад написал статью на Habr, где я говорю, что SSD в тысячу раз быстрее там SATA и ниша для резидентных баз с приходом SSD NVMe сузилась. Она еще есть, но гораздо меньше. 

А потом память в два-три раза подорожала. А что ты будешь делать-то? Заказчик говорит: "Прекрасно! Вы что, золотые, что ли?". 

Алексей Рыбак.  Кость, я прямо сейчас беру Пикодату и могу туда запихнуть данных больше, чем у меня в памяти, да? С движком Tarantula или уже с другим каким-то движком. 

Константин Осипов.  Нет, это будет наш Vinyl. Я расписал статью, где мы взяли Vinyl, который в Тарантуле был изначально, полностью рабочий, вот в кавычках. И я сидел его переписывал, где-то с октября прошлого года. У нас дисковый движок-то был формально всегда. Но когда начали реально тестить под Cassandra нагрузками, то оказалось, что Cassandra в полтора раза меньше места жрет.

И последние полгода очень много вложено в Vinyl, довели все эти кейсы до ума. 

Сейчас на подходе патч, который добавляет Snapshot Isolation level в Vinyl. Оказалось, что по дефолту то, что мы сделали serializable isolation, то есть это сильная консистентность, она, конечно, красивая, но, то есть все как по учебнику. Но только в Postgres – snapshot isolation. И народ привык, как выясняется, к тому, что ему не вылетает, там, transaction has been aborted by conflict, на каждый коммит. 

Алексей Рыбак.  Подожди, не read committed? 

Константин Осипов.   По умолчанию там read committed, но народ в основном сидит в repeatable read, который реализован через snapshot isolation. Мы подвезли обычный repeatable read в Vinyl. С точки зрения UX это оказалось ключевой историей. 

Алексей Рыбак. Это вообще круто, круто, в двадцать пятом, двадцать шестом году вот происходит такое, такая трансформация. Прям прикольно, я тебя с этим поздравляю. Слушай, потихонечку приходит время к концу. Мы договорились сделать короткие выпуски. А, вы следите, ребята, это, надеюсь, далеко не последняя встреча. Можете в комментариях написать, про что было бы интересно поговорить. Кость, мне остается только поблагодарить тебя за то, что ты был моим гостем сегодня. Спасибо тебе большое за эти ответы. 

Это текстовая расшифровка интервью. Полное видео (40 минут) смотрите на канале: https://youtube.com/u/AlexeyRybak. Возможно, вам так же будут интересны канал Алексея Рыбака: https://t.me/rybakalexey и канал Константина Осипова: https://t.me/rabid_transit.