Category: криминал

Гена

Проблемы Постгреса (навскидку)

Сразу оговорюсь, что считаю Постгрес идеальным решением для малых и средних баз не с беспредельной нагрузкой.
Что это такое? Ну, например, "крупный банк федерального масштаба" держит там все заявки и работы ("купить новую инкассаторскую машину", "Марь Петровна жалуется, что ей нахамила операционистка" и т.п.)
На нем живет Авито - и им хватает.
На самом деле эта планка очень высокая, очень мало у кого есть требования, превышающие вышеуказанные.
Извините, но для 90% БД брать не Постгрес, а что-то пропиетарное - это либо идиотизм, либо коррупция.

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

1. Отсутствие внятного секционирования. Родное понимает только литералы, но не понимает параметры/колонки других таблиц. Иногда этого вполне достаточно (но тогда толку от него не так уж и много).
К чему ведет: проблемы с очень большими таблицами - очень большие таблицы для постгреса это плохо, а на маленькие нужным образом нарезать не получается.
Способы решения: pg_pathman (не без недостатков - секционирование только одноуровневое, нет глобальных индексов, нет отдельно секционированных индексов, сделать 500 тыс. секций очень скверная идея, но все сильно лучше того, что есть сейчас - а по факту сейчас ничего нет)
2. Компрессия - она есть только для колонок переменной длины, что не очень удобно, точнее, совсем неудобно; ситуация усугубляется еще и тем, что у постгреса высоки накладные расходы на строку, теоретически от 23 байт, фактически - с учетом выравнивая - 32 байта.
Есть компрессия ведущих колонок в индексе отдельным патчем, но из-за выравнивания от нее порой мало толка.
К чему ведет - большой объем данных, большой ввод-вывод, неэффективное расходование кеша.
В PostgresPro Enterprise есть компрессия, для варианта append-only таблиц вполне себе симпатичная. В ванильном нет и непонятно, когда будет, если вообще будет.
3. Вакуум - в настоящий момент только однопоточный (см. выше про таблицы), в версиях до 9.6 иногда остро вставала проблема wraparound'а (это выглядит как "база встала колом и третьи сутки что-то делает". Для бизнеса такое может быть кошмаром); но при желании этого можно добиться и на 9.6. В PostgresPro Enterprise она решена, может быть, попадет и в ваниллу.
4. Средства мониторинга и администрирования - вообще говоря, уже есть вчерне патч с wait events, разнесенный по statement'ам, но именно что вчерне. К сожалению, особого прогресса в этом не видно. С собственно инструментами все достаточно безрадостно - нет ни инструментов, ни толковой инфраструктуры.
5. Push executor/компиляция запросов в нативный код - есть наработки, но пока особого прогресса не видно и перспективы весьма туманны. Это сильно снижает производительность на больших выборках.
6. IOT - нет и не очень понятно, как их делать. Пока только разговоры.
8. Параллелизм на большом количестве ядер (эдак 256-384 и выше).
7. Куча всякого, иногда критически важного - инкреметальный бекап, чексуммы на clog, лимиты на запросы, триггеры на логин, трассировка выбранных сессий и т.д. и т.п.
8. Идиотская проблема, когда асинхронная реплика влияет на мастер.

Чтобы было понятно, на каких размерах у постгреса начинаются проблемы я постараюсь привести пару примеров:

Одна из госорганизаций решила контролировать каждый шаг граждан и лиц с видом на жительство. Предполагалось вживить каждому чип с приемником глонасс и собирать данные по шагам, возможна заливка данных пачками, задержка не более суток. Проект не был реализован в варианте с постгресом, так как постгрес оказался не готов к такому объему, тем более что требовалось хранить юридически значимые данные (т.е. с цифровой подписью), что еще более затрудняло задачу. Система должна была обеспечивать обнаружение фактов слежения одних граждан или лиц с видом на жительство за другими, время запроса для одного лица не более 60 сек., операторов не менее 2000.
Суть проблемы - невозможность обеспечить в рамках одного сервера/или консистентного представления указанные требования. В настоящий момент реализуется на импортном оборудовании и ПО.

Одна из компаний организовала стартап с генетически модфицированными муравьями для сопровождения грузов. Через каждые 50-500 метров муравьи выбегают из машины и бегут в ближайший спецмуравейник, где и выгружают данные об автомобиле (координаты, скорость, погодные условия) и грузе (состояние, комлектность (думаете, водители не воруют? О, как они воруют!), масса). Не знаю, чем кончилось, но были большим проблемы с постгресом - заливка данных/pgpool дурил и либо вообще останавливал обработку, либо давал неконситентный резльтат. Ну вы поняли про pgpool.

Компания (уж не знаю, по госзаказу или нет) отслеживала все доступные НЛО. Вы не представляете, сколько НЛО изучают нашу бедную планету и как они при этом мотаются по орбитам! Все было хорошо, пока не налетели на врапэраунд (ну да там только этим дело не ограничилось).

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

(no subject)

http://www.lenta.ru/news/2010/07/25/stop/

Стало быть, судоходству в Средиземном и Черном морях угрожали и угрожают террористы, и для обеспечения безопасности используются корабли ВМС многих стран.

Что-то бред какой-то.