Рад, что материал вам понравился. На ваш вопрос я вряд ли отвечу, но поверхностное «гугление» показывает, что есть много специализированного софта, предназначенного для подобных задач. Не исключено, что кто-то и pl/r использует, расширение неспроста так много лет поддерживается :)
Создавать конечно же можно. Даже если у вас там десятки миллионов записей, и в каждой партиции по миллиону — выходит несколько десятков партиций всего. Это не так много.
Отдельная партиция на каждого клиента — звучит несколько избыточно, на мой взгляд. Даже если у вас клиентов миллионы, я думаю, что партиционирование по диапазону все равно удастся уложить во вменяемые рамки, со счетом до десятков партиций. Вряд ли клиенты у вас миллионами каждый месяц в сервис приходят. Такое объективно реально для соцсети крупной, наверное, но в таких случаях всегда много «мертвых» юзеров, которые нет смысла держать в «горячих» партициях.
В общем, зависит от конкретной задачи. Что у вас там за данные, в каком количестве они лежат для отдельного клиента, сколько всего клиентов, насколько критична «онлайновость» вот прям всех данных. Под критичностью я не имею ввиду потребность коммерции раз в год какой-то аналитической выгрузки, такое можно и из архивов достать где-нибудь на стендбае или инстансе отдельном.
В целом, коллега верно ниже упомянул про ограничения, связанные с планировщиком, поэтому я бы начал с того, что посмотрел на задачу повнимательнее. Опишите, что и как, подумаем.
Просто поверьте на слово, я не выбирал «партиционирование», чтобы поощрять неграмотность. Коллеги-организаторы PG Day, которые знают мое маниакальное стремление «вылизать» каждый текст до блеска, чтобы ни одной опечатки, дефиса вместо тире или лишней запятой не проскользнуло, подтвердили бы этот факт. Есть люди, которые всерьез считают, что томик Розенталя у меня является настольной книгой (и не далеки от истины, хотя бумажной копией я не владею).
Я считаю, что есть неграмотность (ниже очень хороший пример про аутентификацию или, как вариант, ненавистный мне «функционал»), а есть — сленг и вошедшие в обиход термины. Партиционирование я отношу ко второй категории. В разговорном языке (а статья все-таки написана на «простом» языке, а не академическом) много неточностей и несоответствий формальным правилам, заимствованных иностранных слов и терминов. Не вижу в этом ничего криминального.
Признаюсь честно, я задумывался, какой из терминов выбрать и даже совещался с коллегой, профессиональным посгресовым DBA. Секционирование — это, строго говоря, правильный вариант, но он показался нам более академическим и слабо употребляемым среди специалистов в профессии. Я лично в своей практике не припомню, чтобы кто-то в профессиональной среде использовал «секционирование» или «секция». Поэтому я решил выбрать более распространенный и широкоупотребимый вариант «партиционирование».
Вы, безусловно, правы. Автор раскрывает эту тему дальше, по тексту статьи. Тут, скорее, не совсем правильно подобны слова автором были. Я сохранил формулировку при переводе, чтобы не выкидывать «слов из песни».
Это палка о двух концах. Возможно, я не понимаю сценарий, когда необходимо хранить время в заведомо неправильной, относительно текущей действительности, таймзоне. Но в такой ситуации, если вы запишите уйму меток в формате «timestamp +03», например (для Московского времени), потом депутаты решат сделать перевод таймзоны, и у вас будет большая проблема с кучей таймстампов, не соответствующих действительности. Дело дойдет либо до усложнения бизнес-логики (вручную в приложении разруливать такие ситуации), либо до внесения изменений в БД для корректировки часового пояса. Я такие приключения наблюдал в крупном продакшене, это очень печально.
> Суть в том, что для того, чтобы получить время в какой-то локальной временной зоне, надо иметь базу данных по смещению времени в прошлом и в будущем (!) на весь диапазон рассматриваемых времён. Как в UTC записать дату «через 6 месяцев в 10 часов МСК», если неизвестно, какое будет тогда смещение?
Иметь базу на будущее — в принципе невозможно. Мы же не можем предсказать, решит наше правительство осуществлять переход на зимнее/летнее время или нет. Нужный брать требуемый timestamptz at time zone и записывать, в приложении отображать at time zone «Europe/Moscow» и своевременно обновлять базы часовых поясов при внесении в них изменений.
Да, в целом правильно, при условии что вы, принимая пользовательский input, явно указываете, в каком часовом поясе приняли время пользователя, опираясь на его настройки или определяя местоположение по IP, например. Иначе входное время будет некорректно интерпретироваться при конвертации.
Лично я склонен согласиться, что в такой ситуации UTC наиболее эффективен и устраняет много ненужных проблем. Но требуется аккуратность с вводом/выводом значений времени.
Более «ленивый» путь — это четко декларировать что ваш сервис / платформа работают по такому-то времени (будь-то Москва, UTC или что-то иное), и что все операции ввода/вывода времени происходят в этой таймзоне. Это складывает ответственность по учету времени на пользователя, но облегчает разработку и эксплуатацию системы.
Я встречал на практике разные примеры, вопрос в том, что бизнес-задача позволяет. Какой-нибудь серьезный финансовый инструмент практически наверняка должен уметь адекватно работать в условиях пользователей из широкого спектра часовых поясов.
Возможно, коллеги предложат сценарии, когда использование UTC в качестве основной настройки сервера СУБД нежелательно.
Честно говоря, не совсем понял суть проблемы. Поясните, пожалуйста, на примере. В PostgreSQL нет такого понятия как беззнаковый целый тип, также как и в самом стандарте, если мне не изменяет память. Эмулировать «беззнаковость» можно накладываемым на таблицу ограничением (CHECK). У нас такой потребности не возникало. Значения мигрировались в стандартные целые типы PG безо всяких проблем, диапазонов integer или bigint всегда хватало, чтобы вместить все данные. С сортировками при этом проблем вообще никаких не будет.
with values_ as (select * from generate_series(-10, 10) order by random()) select * from values_ order by 1 asc;
generate_series
-----------------
-10
-9
-8
-7
-6
-5
-4
-3
-2
-1
0
1
2
3
4
5
6
7
8
9
10
> Просто вставьте новую колонку в таблицу с 100кк записей.
«Кто в армии служил, тот в цирке не смеется»
Самый верный признак роста базы и проекта, это когда приходит к тебе программист, и спрашивает, как добавить в MySQL таблицу колонку, не уводя сервис в «оффлайн» :-)
Спасибо за комментарий, очень жаль, что он с отрицательным рейтингом.
Как я уже пояснял коллегам в «треде», это был скорее здоровый сарказм с целью обратить внимание на «грехи» MySQL, а ни в коем случае на поливание «грязью». Я сам спокойно отношусь к MySQL и работаю с ним, когда приходится. Хотя конечно, чего уж там греха таить, у нас в 404 Group, PostgreSQL — основная инженерная специализация, мы «посгрес» очень любим и даже конференцию про него делаем. Так что определенная доля евангелизма, безусловно, имеется.
В целом, все это очень субъективно, и я сужу по своей «песочнице». В компании я многие проекты веду в роли куратора и наставника, а не непосредственного «техлида». В таких случаях, если ребята хотят попробовать применить MongoDB для хранения данных или ZeroMQ для реализации очередей, я ни в коем случае не запрещаю. Я вообще за развитие и всяческую «движуху» :)
И Вы все-таки не правы, позволю себе не согласиться. Статья именно про конкретный «кейс» миграции с MySQL на PostgreSQL, от тематики я не уходил. У меня «за плечами» около 10 крупных миграций с MySQL, в том числе очень нагруженных проектов. Три года назад я мигрировал базу, где полтерабайта транзакционных логов в сутки набегало одним лишь биллингом. Сейчас вот с коллегами в процессе переключения на PG кластера MySQL, который суточно принимает нагрузку около миллиарда записей. Описанные проблемы MySQL — это то, с чем регулярно приходиться бороться при подготовке к миграции практически любой сделанной с его помощью базы данных.
Всех этих проблем можно избежать, если правильно «готовить» MySQL. Я несколько лет назад стартовал крупный проект с командой, и мы еще тогда применяли MySQL и вознамерились не повторить ни единой ошибки, из числа допущенных коллегами. У нас это получалось, но было крайне тяжко и мучительно. Взять ту же репликацию. В MySQL она принципиально так устроена, чтобы создавать проблемы. Нужно весь код внимательно вычитывать на предмет репликационно-небезопасных функций, коих там превеликое множество. Очень нервная работа. В PostgreSQL репликация работает и про нее не помнишь.
Вы абсолютно правы в том, что PostgreSQL не обладает принципиальными преимуществами, это просто хорошая и надежная база. В моей практике так уж сложилось, что PostgreSQL у нас just works, а с MySQL — вечные трудности. И это далеко не от недостатка компетенций. У нас крутые админы и DBA с большим опытом. Поэтому я привожу в пример те проблемы MySQL, которые знаю. На крупных проектах, которыми я обычно «рулю», они особенно болезненны. На мелких — просто неприятны, но не смертельны.
Кто-то сильно не любит PostgreSQL и имеет на это право. Я регулярно провожу PostgreSQL-секцию на Питерском слете IT-сообществ Piter United (кстати, если Вы из Питера, приходите в эту субботу, буду рад пообщаться и всех коллег из «треда» приглашаю). На последнем таком слете коллега рассказывал о том, как им надоел PostgreSQL с безумной логикой, написанной с помощью хранимых процедур, и они «мигрились» на Джаву. С удовольствием прослушал доклад и пообщался со спикером.
Я буду рад написать еще одну или две статьи про конкретные примеры миграции, как только время позволит. Просто сильно опасаюсь, что это будет воспринято как негатив в сторону MySQL, т.к. мой опыт связан, преимущественно, с ним. Но я постараюсь что-нибудь придумать :)
Это была ирония, я даже смайлик специально поставил.
Да и на самом деле, чем плохи эти задачи, если разыскивается кандидат, обладающий знаниями тонкостей реализации и в целом владеющий продуктом на уровне «advanced»? Я вот, например, ответы на первую и вторую сообразил, благодаря наличию некоторого опыта, а с третьей пришлось заглянуть под «спойлер».
В общем, не вижу в этом ничего плохого. Я регулярно выдаю программистам вариацию задачи на сотрудников без отделов как часть тестового задания (хотя, это все-таки банальная проверка на знание SQL). Если кандидат утверждает, что он хорошо знает PostgreSQL, я обязательно спрошу что-нибудь про внутреннее устройство.
Я с упомянутой Вами конструкцией из Oracle не знаком, поэтому прокомментировать не могу. Но вот приведенный мой пример совершенно «разрывает шаблон», поскольку в таком запросе совершенно не ясно, как себя поведет MySQL: сделает IGNORE или все-таки обновит запись согласно ON DUPLICATE KEY UPDATE. Как мне кажется, это вещи взаимоисключающие, и странно их видеть в одном и том же запросе.
Но так-то Вы конечно правы, стрелять по ногам позволяет любая база.
Отдельная партиция на каждого клиента — звучит несколько избыточно, на мой взгляд. Даже если у вас клиентов миллионы, я думаю, что партиционирование по диапазону все равно удастся уложить во вменяемые рамки, со счетом до десятков партиций. Вряд ли клиенты у вас миллионами каждый месяц в сервис приходят. Такое объективно реально для соцсети крупной, наверное, но в таких случаях всегда много «мертвых» юзеров, которые нет смысла держать в «горячих» партициях.
В общем, зависит от конкретной задачи. Что у вас там за данные, в каком количестве они лежат для отдельного клиента, сколько всего клиентов, насколько критична «онлайновость» вот прям всех данных. Под критичностью я не имею ввиду потребность коммерции раз в год какой-то аналитической выгрузки, такое можно и из архивов достать где-нибудь на стендбае или инстансе отдельном.
В целом, коллега верно ниже упомянул про ограничения, связанные с планировщиком, поэтому я бы начал с того, что посмотрел на задачу повнимательнее. Опишите, что и как, подумаем.
Я считаю, что есть неграмотность (ниже очень хороший пример про аутентификацию или, как вариант, ненавистный мне «функционал»), а есть — сленг и вошедшие в обиход термины. Партиционирование я отношу ко второй категории. В разговорном языке (а статья все-таки написана на «простом» языке, а не академическом) много неточностей и несоответствий формальным правилам, заимствованных иностранных слов и терминов. Не вижу в этом ничего криминального.
Иметь базу на будущее — в принципе невозможно. Мы же не можем предсказать, решит наше правительство осуществлять переход на зимнее/летнее время или нет. Нужный брать требуемый timestamptz at time zone и записывать, в приложении отображать at time zone «Europe/Moscow» и своевременно обновлять базы часовых поясов при внесении в них изменений.
Лично я склонен согласиться, что в такой ситуации UTC наиболее эффективен и устраняет много ненужных проблем. Но требуется аккуратность с вводом/выводом значений времени.
Более «ленивый» путь — это четко декларировать что ваш сервис / платформа работают по такому-то времени (будь-то Москва, UTC или что-то иное), и что все операции ввода/вывода времени происходят в этой таймзоне. Это складывает ответственность по учету времени на пользователя, но облегчает разработку и эксплуатацию системы.
Я встречал на практике разные примеры, вопрос в том, что бизнес-задача позволяет. Какой-нибудь серьезный финансовый инструмент практически наверняка должен уметь адекватно работать в условиях пользователей из широкого спектра часовых поясов.
Возможно, коллеги предложат сценарии, когда использование UTC в качестве основной настройки сервера СУБД нежелательно.
Так действительно скоро дойдем до STRICT MODE = Off.
«Кто в армии служил, тот в цирке не смеется»
Самый верный признак роста базы и проекта, это когда приходит к тебе программист, и спрашивает, как добавить в MySQL таблицу колонку, не уводя сервис в «оффлайн» :-)
Спасибо за комментарий, очень жаль, что он с отрицательным рейтингом.
Как я уже пояснял коллегам в «треде», это был скорее здоровый сарказм с целью обратить внимание на «грехи» MySQL, а ни в коем случае на поливание «грязью». Я сам спокойно отношусь к MySQL и работаю с ним, когда приходится. Хотя конечно, чего уж там греха таить, у нас в 404 Group, PostgreSQL — основная инженерная специализация, мы «посгрес» очень любим и даже конференцию про него делаем. Так что определенная доля евангелизма, безусловно, имеется.
В целом, все это очень субъективно, и я сужу по своей «песочнице». В компании я многие проекты веду в роли куратора и наставника, а не непосредственного «техлида». В таких случаях, если ребята хотят попробовать применить MongoDB для хранения данных или ZeroMQ для реализации очередей, я ни в коем случае не запрещаю. Я вообще за развитие и всяческую «движуху» :)
И Вы все-таки не правы, позволю себе не согласиться. Статья именно про конкретный «кейс» миграции с MySQL на PostgreSQL, от тематики я не уходил. У меня «за плечами» около 10 крупных миграций с MySQL, в том числе очень нагруженных проектов. Три года назад я мигрировал базу, где полтерабайта транзакционных логов в сутки набегало одним лишь биллингом. Сейчас вот с коллегами в процессе переключения на PG кластера MySQL, который суточно принимает нагрузку около миллиарда записей. Описанные проблемы MySQL — это то, с чем регулярно приходиться бороться при подготовке к миграции практически любой сделанной с его помощью базы данных.
Всех этих проблем можно избежать, если правильно «готовить» MySQL. Я несколько лет назад стартовал крупный проект с командой, и мы еще тогда применяли MySQL и вознамерились не повторить ни единой ошибки, из числа допущенных коллегами. У нас это получалось, но было крайне тяжко и мучительно. Взять ту же репликацию. В MySQL она принципиально так устроена, чтобы создавать проблемы. Нужно весь код внимательно вычитывать на предмет репликационно-небезопасных функций, коих там превеликое множество. Очень нервная работа. В PostgreSQL репликация работает и про нее не помнишь.
Вы абсолютно правы в том, что PostgreSQL не обладает принципиальными преимуществами, это просто хорошая и надежная база. В моей практике так уж сложилось, что PostgreSQL у нас just works, а с MySQL — вечные трудности. И это далеко не от недостатка компетенций. У нас крутые админы и DBA с большим опытом. Поэтому я привожу в пример те проблемы MySQL, которые знаю. На крупных проектах, которыми я обычно «рулю», они особенно болезненны. На мелких — просто неприятны, но не смертельны.
Кто-то сильно не любит PostgreSQL и имеет на это право. Я регулярно провожу PostgreSQL-секцию на Питерском слете IT-сообществ Piter United (кстати, если Вы из Питера, приходите в эту субботу, буду рад пообщаться и всех коллег из «треда» приглашаю). На последнем таком слете коллега рассказывал о том, как им надоел PostgreSQL с безумной логикой, написанной с помощью хранимых процедур, и они «мигрились» на Джаву. С удовольствием прослушал доклад и пообщался со спикером.
Я буду рад написать еще одну или две статьи про конкретные примеры миграции, как только время позволит. Просто сильно опасаюсь, что это будет воспринято как негатив в сторону MySQL, т.к. мой опыт связан, преимущественно, с ним. Но я постараюсь что-нибудь придумать :)
Спасибо за конструктивную критику.
Да и на самом деле, чем плохи эти задачи, если разыскивается кандидат, обладающий знаниями тонкостей реализации и в целом владеющий продуктом на уровне «advanced»? Я вот, например, ответы на первую и вторую сообразил, благодаря наличию некоторого опыта, а с третьей пришлось заглянуть под «спойлер».
В общем, не вижу в этом ничего плохого. Я регулярно выдаю программистам вариацию задачи на сотрудников без отделов как часть тестового задания (хотя, это все-таки банальная проверка на знание SQL). Если кандидат утверждает, что он хорошо знает PostgreSQL, я обязательно спрошу что-нибудь про внутреннее устройство.
Но так-то Вы конечно правы, стрелять по ногам позволяет любая база.