Как стать автором
Обновить

Комментарии 27

Кажется, у вас в статье потерялся план про риак — о нём только в самом начале. Про миграцию с него было бы очень интересно прочитать.
Данные из Riak мигрировали через уже существующий механизм на серверной стороне, который извлекал порцию «холодных» данных и помещал в Redis.
И с этим проблем не возникло? Один в один смигрировалось?
Этот механизм «разархивации» из Riak уже был обкатан, он использовался на prod не один год, наша команда лишь оптимизировала его для большей производительности. Поэтому особых проблем не возникло. Также добавили дополнительные сервера «разархиваторы», которые вытаскивали данные из Riak параллельно.

Да, данные один в один. Но нам также приходилось фиксить неконсистентные данные, если мы такие находили.
А в паблике есть? Или может планирует выложить? Наверное, вы уже поняли, что у меня интерес не теоретический…
В паблике сейчас нет, но уточню в ближайшее время сможем ли что-то выложить.
Спасибо за статью.
Писали, что что-то пошло не так. Хотелось бы подробнее о технических проблемах.
Технические проблемы будут в следующих частях.
Мы провели исследование, чтобы выбрать оптимальную БД для нас, и остановились на PostgreSQL. Наша модель данных хорошо ложиться на реляционную БД: у PostgreSQL есть встроенные инструменты для обеспечения консистентности данных, есть тип JSONB и возможность индексации определенных полей в JSONB. Это нам подходит.

во-первых — «ложиться». Режет глаз.
во-вторых, вы сами себе придумываете приключения. По сути — планируете использовать PostgreSQL как KV, но с дополнительными вторичными индексами. Очень интересно — чем же все-таки Riak не подошел. Или что-то посвежее. Вроде Couchbase, Cockroach etc.
Второе измерение — почему не RDS или managed инстансы? Сами все готовили?
И что там с шардированием-репликацией? Это же в Постгрес настраивать прямо боль, хотя вот коллеги из Zalando как-то справляются. И все-таки как обеспечивается целостность данных (понимаем, что транзакционность на уровне инстанса БД != транзакционность на уровне распределенной системы + особенности хранения/передачи/синхронизации данных).
«Ложится» поправили. Спасибо за внимательность.
И что там с шардированием-репликацией? Это же в Постгрес настраивать прямо боль

Намного больнее блокировки кластера «обычно, не более чем на 12 секунд» при падении мастера у Монги?
Я про монгу ничего не говорил, между прочим, и никому ее не рекомендовал.
Мы выбирали между RDS и своими инстансами EC2 в AWS, посчитали, что для нас выгоднее свои инстансы. Готовили сами.
Для шардирования рассматривали несколько вариантов (citus, pg_shardman, etc) — везде были проблемы. В итоге остановились на шардировании на стороне серверного приложения. Т.е. приложение знает с какой базой работать. Об этом напишу подробней в следующих частях.
Да, очень интересно, ждем дальнейших материалов. Спасибо.
10 лет назад все переезжали с Sql на NoSql.

Это уже третья статья на хабре про миграцию с NoSQL на SQL. Предыдущие две:
Mongo => Postgres, 14 марта 2015 года — habr.com/ru/post/253075
Mongo => Postgres, 17 января 2019 — habr.com/ru/company/itsumma/blog/436416
Кажется, это новый тренд — переезд с NoSql на Sql.

Ждать ли через 10 лет тренд «все срочно переезжаем с SQL на NnnSql»?
Не, наверное на что-то гибридное или какие не будь нейробазы с менеджером в виде нейросети, которая будет вспоминать данные.
Мы тоже так делали. Сначала перевели часть проектов с MySQL 5.5 на Монгу, выяснили, что у неё тоже проблем хватает. Тут подоспел Postgres 9.4 с нормальной поддержкой JSON и обнаружилось, что из десятка наших проектов только в двух Монга работала лучше, во всех остальных она с треском проигрывала Постгресу.
Т.е. Вы умеете уже готовить Постгрес и Вас не пугают особенности его работы?
Вот, например, парни из TimeScaleDB сделали из Постгресса что-то типа TSDB (а-ля Influx, VictoriaMetrics, Prometheus LevelDB etc.). Результат — к эксплуатации практически не пригодно (это вообще нормально, когда индексы по объему == кол-ву данных?). Я уж не говорю про всякие «радости» типа вакуума (и пускай весь мир подождет).

DISCLAIMER: я не спец по постгресу, просто мимо проходил.
если сильно постараться, можно добиться индексы объему > данных.

иногда это делается не случайно, а специально (olap).
Допускаю, что в таких случаях возможно проще перелить данные из Постгреса в тот же Кликхаус, например. И крутить кубы уже на последнем…
не пугают особенности его работы

Пугать — не пугают, но у нас с ним проблем, чем с Мускулем и Монгой. В одном проекте он даже Сфинкса наполовину «выдавил».
Пока из особенностей словили только ненависть к длинным транзакциям и неожиданное (после мускуля и монги) целочисленное деление, что-то с UPSERT. Но многие вещи даже не опробованы — то же секционированием с «шардированием» через postgres_fdw.
С вакуумом проблем пока не было, даже со стандартными настройками, но каждое второе руководство по настройке советует делать задачи вакуума менее объёмными, чтобы мир не ждал.

к эксплуатации практически не пригодно

Только сейчас узнал, что TimeScaleDB — расширение Постгреса )
Всякое возможно: DNSFilter перешли с InfluxDB на TimeScaleDB и довольны.
Впрочем, кое-кто из разрабов ClickHouse с вами согласен и утверждает, что и TimeScaleDB, и InfluxDB «просто недоработаны, и ими стыдно пользоваться».
Возможно вы что-то не то сделали (мы вот не нашли нужны нужной «ручки» у монги, чтобы count(*) по скромным 14 гигам журналов не минуту тупил, а админам у моего друга это удалось, жаль не знаю как), может TimeScaleDB уже исправил те проблемы, а ребятам из DNSFilter ещё только предстоит получить граблями по лбу.

индексы по объему == кол-ву данных

В первой версии SphinxSearch только индексы и хранил. Задача у него такая была.
Всякое возможно: DNSFilter перешли с InfluxDB на TimeScaleDB и довольны.

а ребятам из DNSFilter ещё только предстоит получить граблями по лбу.

Выбор технологии — это же бизнесовая история. Может они все посчитали, всю экономику. И может оказалось, что недостатки несущественны, стоимость владения не столь велика, а преимущества (например, полноценный SQL и возможность обогащать данными JOIN'ами) перевешивают…
Собственно, вся суть метания была в архитектурном недостатке, о котором все успешно забыли или подумали что, ну блин все переходят на PostgreSQL. А недостатком оказался всем любимый автовакуум, ребята решили быстро и шустро читать с реплик, а не вышло)))
Либо обрыв запросов на реплике, так как на мастере автовакуум побежал уже по этим данным, либо если включен фидбэк на реплике, распухание мастера и возможное чтение устаревших данных.
И второе из-за «особенностей» работы автовакуума следует ждать большего кол-ва IOPS
MySQL этого лишен за счет UNDO log
я думаю, есть кейсы, в которых лучше sql.
есть кейсы в которых лучше nosql.

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