В дебрях водопада

[vit_r]

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

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

Comments

[orleanz.livejournal.com]

Интересуют и технические подробности

[vit-r.livejournal.com]

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

Одни говорят:

- А, вдруг, ключи не правильные. Ну и что, что у них «_key» в названии. Может где-то какой-то другой скрипт делает запрос по другим столбцам.

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

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

Ещё есть куча нетехнических подробностей, но они все ДСП

[cross-join.livejournal.com]

Что за СУБД?

[vit-r.livejournal.com]

А есть разница?

[cross-join.livejournal.com]

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

[vit-r.livejournal.com]

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

С тем случаем, который повалил кластер, тоже сначала думали, что из-за объёма данных. Оказалось, что из-за диких идей планировщика при настройках без жёстких ограничений на его фантазию.

[cross-join.livejournal.com]

Прежде всего зависит от физической архитектуры хранения, терабайты ведь не в ОЗУ сидят постоянно.

[vit-r.livejournal.com]

Фиг знает. Если тупо создать копии таблиц с правильным DISTRIBUTED BY (как это по русски), то общее время сокращается с часов до минут. Я всё-таки думаю, что там проблемы именно с коммуникацией.

[cross-join.livejournal.com]

DISTRIBUTED BY - это нестандартное расширение, по сути это вертикальное секционирование таблицы, но не по единицам хранения (устройствам), а по единицам обработки (узлам).
Разумеется, запрос по условию с тремя колонками, разнесенных по узлам, будет выполняться быстрее, чем на одном узле.
Если узлы имеют свои независимые системы хранения, то все нормально, а если они все сидят на некотором большом массиве, то это нивелирует преимущества и может быть даже хуже, чем запрос к одному узлу с поколоночно секционированной по многим устройствам хранения таблицей.

[vit-r.livejournal.com]

Это просто указание планировщику, как раскладывать данные для улучшения доступа.

А хуже-лучше это в любом случае гадание. Надо смотреть запросы на реальных данных.

[gorba.livejournal.com]

Гражданина Хакамада?

[vit-r.livejournal.com]

Кто это такая и к чему вопрос?

[gorba.livejournal.com]

http://www.kulichki.com/vv/pesni/opasayas-kontrrazvedki-izbegaya-zhizni.html