Comments 16
Шардинг, PostgreSQL - все это, конечно, круто.
Стандартный вопрос - когда поиск заработает нормально?
Хотя-бы до того уровня, как ваши кривые руки за него и приложение взялись?
Чтобы можно было хотя-бы нормально искать на площадке, а не через гугл или global?
Чтобы можно было сортировать по цене с учетом доставки или по дате размещения, и чтобы при этом не пропадала бОльшая часть товаров, под этот критерий подходящих, и не появлялась тех товаров, к которым запрос вообще не относился?
Зачем вам все эти навороты, если вы даже элементарный базовый поиск и сортировку обеспечить не можете?!
P.S. про приложение я вообще молчу...
Простите, а 500гб это что, много?
64 шарда по 500 гигов и заполненность на 60%. Ты только на картинку посмотрел и коммент сразу пошел писать?
Нет, вопрос остаётся, зачем так мелко резать. Всего у вас получается 32Тб. У нас на одном сервере 95Tb
У нас на одном сервере 95Tb
Ну, 95тб можно использовать по-разному.
Если OLTP с массой RI правил на одном сервере, то можно увязнуть в deadlocks, особенно при "грамотной" архитектуре.
А если блобы хранить, то и 95тб не предел.
Скорее всего компромисс для сохранения даунтайма сервисов в разумных пределах при обслуживании БД, например, при подъёме её major версии. Ванильная постгря не умеет фиксировать планы (ни тебе бейслайнов, ни sql profile-ов, ни даже банальных хинтов) и не умеет переиспользовать/конвертировать статистику при подъёме мажорной версии (PostgreSQL: Documentation: 16: pg_upgrade), так что либо здравствуй, полный пересбор статистики после апгрейда и ДО запуска траффика на БД, либо абсолютно невменяемые планы половины запросов, шатающие базу, пока таковая не соберётся. Сколько будет собираться статистика с нуля на базе в 95Тб, боюсь представить. Явно дольше, чем на 500 гигах.
Мда. Чем больше узнаешь...
Я понимаю что в России Постгре выбирают про понятным причинам, но в других странах... окупает ли бесплатность Постгре затраты на время тех, кто обходит все эти грабли?
Всё верно, это компромисс между скоростью рестора и объёмом данных в шарде.
Плюс такой объём удобнее размазывать по железу без использования сетевых стораджей и рейдов поверх nvme.
Нет, вопрос остаётся, зачем так мелко резать.
В статье же был на него ответ:
на одну базу установлен лимит в 500 ГБ от инфры, связанный с возможностью оперативно решать проблемы с таким объемом данных.
Что-то, похоже, им там в инфраструктуре не позволяет резать крупнее (хотелось бы, конечно, подробностей, но в целом понятно).
И не надо равнять PostreSQL и MS SQL: у PostgreSQL существенно другая, многоверсионная, схема управления памятью для данных в базе. Такая схема требует для освобождения этой памяти сборки мусора (AFAIK в псотгресе это именуется vacuum). А к MS SQL (в отличие от .NET ;-) ) Microsoft сборку мусора пока (AFAIK) не прикрутила ;-).
Раз уж данных много и пришлось шардировать то почему бы для этих данных не взять например Cassandra? Там уже всё украдено до нас, не надо вручную закатывать солнце.
Это у вас корпоративный кодстайл такой с тремя(!) ньюлайнами после каждой строчки, или форматирование поехало?
Работа проделана хорошая и интересная. Но я так и не понял, надо было ли ее делать вообще. Или задачу можно было бы решить по-другому? Загрузить историческую информацию в другие экземпляры(шарды) БД и организовать к ней доступ только по чтению. То есть - сделать своего рода архив. Вы ведь все равно были вынуждены были ради сокращения времени простоя дорабатывать в программе объекты слоя работы с хранилищем, что логика этого слоя работала с двумя копиями БД. Можно ведь было дорабтоать ее так, чтобы чтение данных производилось из двух экземпляров - рабочего и архивного, и результаты бы собирались в одну логическую сущность, с которой уже работает вышележащий слой. Ну а запись при этом всегда бы шла в рабочий экземпляр.
В такой схеме можно было бы сэкономить, например, на дисках: рабочий экземпляр размещен на чем-то быстром, а архивный - на медленном, типа типа HDD на 7200 об/мин. И на резервном копировании тоже экономить можно. Лично я с такими схемами работал с MS Exchange (там сообщения хранятся тоже в БД, пусть и не реляционной), и было вполне работоспособно.
Интересно узнать, если можно - рассматривали ли вы такой вариант, и если да - почему от него отказались.
Записки хирурга. Распиливание слонов PostgreSQL наживую и без анестезии