первые 5 лет мы только вкладывали в бизнес и шли к показателю 100 млн крышечек в месяц, как ослик за морковкой. Меньше 100 млн крышек в месяц производить нерентабельно. Под эти объемы нужны большие площади, дорогое оборудование, квалифицированные технологи, что равно огромные инвестиции.
Статья хорошая, но не хвататет детали, чтобы пазл сложился. Где вы взяли 1,5 миллиарда чтобы открыть большой завод , если до этого бизнес был убыточный ?
Вместо log_min_duration_statement советую pg_store_plans https://ossc-db.github.io/pg_store_plans/ все таки родной sql , это гораздо удобнее чем запись планов в логфайл (особенно, если у вас приличные нагрзуки). И (позвольте немного попиарюсь) к этому , еще прикрутил историю сессий - https://habr.com/ru/companies/uzum/articles/865622/ , и получил практически awr оракловый ). Так что можно жить и с Postgres, просто тут принцип другой, минимум - из коробки.
Автоматизацию для pg_repack на нем делал с вызовом из pg_cron. Зачем-то его реализовали как внешний исполняемый файл, хотя его лоичней из бд вызывать, используя стату для определения bloat таблиц .
Ребят, ну вы хоть комментарии давайте что у вас конфиг на файловер с легитимной потерей данных. Наверное из за таких статей и встречаю в продах такие вот конфиги.
Has the same effect as PLSQL_OPTIMIZE_LEVEL=1—instructs the PL/SQL compiler to generate and store the code for use by the PL/SQL debugger. Oracle recommends using PLSQL_OPTIMIZE_LEVEL=1 instead of DEBUG.
Отечественные СУБД отлично зарекомендовали себя ...
Ну да конечно. Обычно, то что на 99% состоит из open source кода называется форк. ИМХО надо гнать в шею таких "импортозамещателей", наследнички bolgenOS и дела Попова) Ну разве что, PostgresPro еще можно понять, так как они контрибьютор основной ветки.
Ну не знаю.. Продавать такое как продукт... Фио перемашать , ака Третьев Первый Вторвович. Емейлы, телефоны - ну тут понятно простейший генератор. Адреса - есть кладр, или можно также перемешать (города, улицы, дома), если физическое существование не важно. Сохранить в отдельные таблицы, дергать по мере надобности, в нужном кол-ве, при раскатке тест баз, чтоб каждый раз не генерировать.
Плюсую. Известно, же как раз что в крупных компаниях наоборот много уровней иерархии инженеров, и высшие имеют большие полномочия в принятии решений, сравнимые в топ менеджерами. Взять тот же МС, иерархия выглядет примерно так Junior Software Engineer Intermediate Software Engineer Senior Software Engineer Staff Software Engineer Senior Staff Software Engineer Principal Software Engineer Distinguished Software Engineer Fellow Senior Fellow ... Я думаю, общий посыл статьи правильный, просто диавол как всегда в деталях..
О многом ни слова. Да тема такая огромная, что одной статьей не обойтись. Но все же, имхо, автор, зря вы с хинтов начинаете. Начинают разрабы пихать их не к месту после таких статей. Все таки с основ cost based оптимизации лучше. Дальше, что есть estimated планы ( о которых речь в общем то тут и идет), и реальные. А как про реальные планы, так тут и статистика , child cursors, hard/soft parse и plan stability( вот тут о хинтах уже можно, наряду с outlines).
Кто то еще использует Oracle SE ? Давно работаю с Oracle, не помню когда встречал его последний раз, точно лет 10 прошло. С момента появления enterprise фич в opensorce бд (типа partitioning, HA, incremental backup) уже как то не особо нужен. Кажется этот рынок Oracle давно проиграл.
Спасибо за статью, но осталось несолько вопросов. Аналитику пернесли, а остальное осталось в PG ? Или это изначально чисто аналитическая БД была ? Если чисто аналитическая, то почему выбрали PG изначально ? Как загружаете данные в Clickhouse ?
Достаточная сложность, при серьезных ограничениях. Почему не захотели пойти классическим путем : RAC + ASM ? И дискгруппы можно собрать (с необходимым redundancy) с неcкольких СХД и проблем с их resize нет на лету, и под vmware работает. По деньгам не готов утверждать что это не дороже, но знаю, что VCS тоже сильно не дешевый.
Решение проблемы split brain — обязательная составляющая кластерного решения. Без этого вообще нет смысла в кластере. И защита от этого есть — различные voting алгоритмы.
Статья хорошая, но не хвататет детали, чтобы пазл сложился. Где вы взяли 1,5 миллиарда чтобы открыть большой завод , если до этого бизнес был убыточный ?
Вместо log_min_duration_statement советую pg_store_plans
https://ossc-db.github.io/pg_store_plans/ все таки родной sql , это гораздо удобнее чем запись планов в логфайл (особенно, если у вас приличные нагрзуки).
И (позвольте немного попиарюсь) к этому , еще прикрутил историю сессий - https://habr.com/ru/companies/uzum/articles/865622/ , и получил практически awr оракловый ). Так что можно жить и с Postgres, просто тут принцип другой, минимум - из коробки.
Вроде более удобным способом можно удалять гланды - https://postgreshelp.com/postgresql-checksum/?source=post_page-----33806f44b1c4-------------------------------
Хотя, честно говоря, сам
таким еще не страдалне пробовал - т.к. бэкапы, enabled pg_checksum, и standby db для критичных данных.Автоматизацию для pg_repack на нем делал с вызовом из pg_cron. Зачем-то его реализовали как внешний исполняемый файл, хотя его лоичней из бд вызывать, используя стату для определения bloat таблиц .
Ребят, ну вы хоть комментарии давайте что у вас конфиг на файловер с легитимной потерей данных. Наверное из за таких статей и встречаю в продах такие вот конфиги.
Изначальный выбор Оракла, просто как хранилку данных шарда, без логики.. выглядет кхм.. не совсем рационально.
Можно добавить, что compile с debug mode отрицательно влияет на производительность psql кода,
ну и в доку заглянуть всегда не мешает (19с) :
Hidden text
https://docs.oracle.com/en/database/oracle/oracle-database/19/lnpls/COMPILE-clause.html#GUID-FB890581-9F65-474B-9D86-6E318110AD5F
DEBUG
Has the same effect as PLSQL_OPTIMIZE_LEVEL=1—instructs the PL/SQL compiler to generate and store the code for use by the PL/SQL debugger. Oracle recommends using PLSQL_OPTIMIZE_LEVEL=1 instead of DEBUG.
Ну да конечно. Обычно, то что на 99% состоит из open source кода называется форк. ИМХО надо гнать в шею таких "импортозамещателей", наследнички bolgenOS и дела Попова)
Ну разве что, PostgresPro еще можно понять, так как они контрибьютор основной ветки.
Обычно ответ - ACID, если ACID требования нет, транзакционность не нужна, тогда да хранить и обрабатывать json в pg - дорого и неэффективно.
Ну не знаю.. Продавать такое как продукт...
Фио перемашать , ака Третьев Первый Вторвович.
Емейлы, телефоны - ну тут понятно простейший генератор. Адреса - есть кладр, или можно также перемешать (города, улицы, дома), если физическое существование не важно. Сохранить в отдельные таблицы, дергать по мере надобности, в нужном кол-ве, при раскатке тест баз, чтоб каждый раз не генерировать.
Статья-то неплохая, спасибо, что делитесь опытом, блок-схемы интересные, но согласен название - муть.
Плюсую. Известно, же как раз что в крупных компаниях наоборот много уровней иерархии инженеров, и высшие имеют большие полномочия в принятии решений, сравнимые в топ менеджерами.
Взять тот же МС, иерархия выглядет примерно так
Junior Software Engineer
Intermediate Software Engineer
Senior Software Engineer
Staff Software Engineer
Senior Staff Software Engineer
Principal Software Engineer
Distinguished Software Engineer
Fellow
Senior Fellow ...
Я думаю, общий посыл статьи правильный, просто диавол как всегда в деталях..
О многом ни слова. Да тема такая огромная, что одной статьей не обойтись.
Но все же, имхо, автор, зря вы с хинтов начинаете.
Начинают разрабы пихать их не к месту после таких статей.
Все таки с основ cost based оптимизации лучше. Дальше, что есть estimated планы ( о которых речь в общем то тут и идет), и реальные.
А как про реальные планы, так тут и статистика , child cursors, hard/soft parse и plan stability( вот тут о хинтах уже можно, наряду с outlines).
Задачу получения консистентного бэкапа всех шардов как решили ?
Кто то еще использует Oracle SE ? Давно работаю с Oracle, не помню когда встречал его последний раз, точно лет 10 прошло. С момента появления enterprise фич в opensorce бд (типа partitioning, HA, incremental backup) уже как то не особо нужен. Кажется этот рынок Oracle давно проиграл.
Спасибо за статью, но осталось несолько вопросов.
Аналитику пернесли, а остальное осталось в PG ? Или это изначально чисто аналитическая БД была ? Если чисто аналитическая, то почему выбрали PG изначально ?
Как загружаете данные в Clickhouse ?
Достаточная сложность, при серьезных ограничениях. Почему не захотели пойти классическим путем : RAC + ASM ? И дискгруппы можно собрать (с необходимым redundancy) с неcкольких СХД и проблем с их resize нет на лету, и под vmware работает. По деньгам не готов утверждать что это не дороже, но знаю, что VCS тоже сильно не дешевый.
Для нагруженных БД перевыбор мастера (slaves в RO, когда один из них выбирается новым мастером, происходит рестарт БД) очень даже заметен.