Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
Все новые и новые фичи добавляются… Но когда же допилят репликацию до «коробочного» состояния «настроил-и-забыл», как в Монге или даже лучше? Уже ж столько лет прошло, и вещь это совершенно необходимая. А воз и ныне там — правим файлики руками и выполняем рукодельные команды в командной строке только для того, чтобы сделать свичовер/фэйловер или добавить новую машину.
если это мало кому нужно, чего его пилить?
меня даже более простой интересует — партиционирование таблиц, тоже не очень приятно руками делать, и тоже «вроде бы как» не должно быть сильно трудно автоматизировать. Но видимо, кому нужно — те руками делают, работа ведь редкая, может быть вообще одноразовая.
меня даже более простой интересует — партиционирование таблиц, тоже не очень приятно руками делать, и тоже «вроде бы как» не должно быть сильно трудно автоматизировать. Но видимо, кому нужно — те руками делают, работа ведь редкая, может быть вообще одноразовая.
К сожалению люди которые пилят БД как правило делают именно БД, а не инструмент для других людей. Они далеки от потребностей проектов, а тем более проектов высоконагруженных. Им интересней теоритические фичи. А необходимый UPSERT который есть у всех пилится годами. Это печально.
Это конечно не отменяет что постгря лучшее из того что есть =)
Это конечно не отменяет что постгря лучшее из того что есть =)
почему «к сожалению»? Всё правильно, до тех пор, пока мы не говорим «БД = продукт».
Если у нас БД, это такая чудо технология — нивапрос.
С другой стороны, очевидно же, люди которые пилят, на что-то живут, откуда-то получают деньги за свою работу? И елси те, кто готов платить деньги «за БД», не строят кластеры, не разбивают таблицы на части, то это и не пилят. А пилят то, что за что реально платят деньги.
Если у нас БД, это такая чудо технология — нивапрос.
С другой стороны, очевидно же, люди которые пилят, на что-то живут, откуда-то получают деньги за свою работу? И елси те, кто готов платить деньги «за БД», не строят кластеры, не разбивают таблицы на части, то это и не пилят. А пилят то, что за что реально платят деньги.
> к сожалению
Ну как почему? Потому что остается целая не окученная ниша. Тут либо оракл брать в котором куча всего есть, но это априори не наш вариант. Либо лапу сосать, придумывая очередные костыли для постгри. Как все и делают. Печально… потому и «к сожалению».
А к деньгам тут весь диалог сводить не правильно. Как и в большинстве крупных открытых проектов там всего понамешено: начиная от энтузиазма,… через всякие фондейшены, донат и много чего еще… заканчивая зарплатой.
Ну как почему? Потому что остается целая не окученная ниша. Тут либо оракл брать в котором куча всего есть, но это априори не наш вариант. Либо лапу сосать, придумывая очередные костыли для постгри. Как все и делают. Печально… потому и «к сожалению».
А к деньгам тут весь диалог сводить не правильно. Как и в большинстве крупных открытых проектов там всего понамешено: начиная от энтузиазма,… через всякие фондейшены, донат и много чего еще… заканчивая зарплатой.
Почему неправильно? Это же opensource, если в этой нише, вы видите деньги — наймите людей, пусть окучат. Вдруг найдутся энтузиасты, и так далее.
Я знаю сколько стоит Оракл, уверен, даже за деньги одной-двух лицензий энтерпрайз версии оракла некоторые вещи по облегчению развертывания и обслуживания кластеров PostgreSQL точно можно решить.
И конечно, там всё намешано, но как показывает жизнь, этой мешаниной должен кто-то управлять, а он хочет как минимум есть сам, и кормить семью.
Я знаю сколько стоит Оракл, уверен, даже за деньги одной-двух лицензий энтерпрайз версии оракла некоторые вещи по облегчению развертывания и обслуживания кластеров PostgreSQL точно можно решить.
И конечно, там всё намешано, но как показывает жизнь, этой мешаниной должен кто-то управлять, а он хочет как минимум есть сам, и кормить семью.
[оффтоп] Какое там «хочеть есть сам» (умолчим про семью)… настоящий опенсорсник должен питаться флюктуациями мозга одними, сдобренными небольшой порцией радости довольных «клиентов»… Всегда в предвкушении сложной задачи… ну и т.д. и т.п.
Не в качестве претензии к комментаторам выше, просто лирическое отступление, так сказать от опенсорсника. [/оффтоп]
По теме же ветки: свои болячки есть и у таких монстров как ORA и (не побоюсь упомянуть всуе) у MSSQL, кто в теме, знает… И то что там из коробки преф-девочки-пряники-конфеты только чуть-чуть оправдывают их стоимость. А радости от того, что это все есть и даже саппорт худо бедно работает, к примеру та же поехавшая мастер-мастер репликация, с результатом «восстановите» вчерашний бакап transaction log-а, приносит тоже мало (от слова совсем).
При том, при всем, что я например себя гораздо комфортнее чувствую юзая PG или тот же мускуль (хотя работать приходится к сожалению больше с верхними двумя)… Как-то так.
Не в качестве претензии к комментаторам выше, просто лирическое отступление, так сказать от опенсорсника. [/оффтоп]
По теме же ветки: свои болячки есть и у таких монстров как ORA и (не побоюсь упомянуть всуе) у MSSQL, кто в теме, знает… И то что там из коробки преф-девочки-пряники-конфеты только чуть-чуть оправдывают их стоимость. А радости от того, что это все есть и даже саппорт худо бедно работает, к примеру та же поехавшая мастер-мастер репликация, с результатом «восстановите» вчерашний бакап transaction log-а, приносит тоже мало (от слова совсем).
При том, при всем, что я например себя гораздо комфортнее чувствую юзая PG или тот же мускуль (хотя работать приходится к сожалению больше с верхними двумя)… Как-то так.
Простите, но я в разном opensource софте ковыряюсь уже лет 18 по необходимости. Иногда мне кажется, что лучше бы некотоыре «настоящие опенсорсники» из вашего определения, занимались чем-то другим. Например, пахали в каком-нибудь «кровавом энтерпрайзе», что бы исходных текстов результатов их деятельности не было видно, а в продуктовые результаты модно было тыкать палочкой с репликой «это же корпоративный говнософт, что бы вы от него хотите?»
Oracle это ад администрирования. Хоть за деньги, хоть за бесплатно — «привет из 80-ых».
MSSQL давно не касался, когда касался — всё было в лучших традициях Майкрософта — простые вещи сделать легко, сложные — или невозможно вообще, или не знаю какими усилиями.
У меня в PG, по-большему счету, никаких претензий нет, кроме того, что это в текущем виде, именно что база данных, а не продукт СУБД. Для 90-ых — это круто, для начала 2016 — нууу, ок.
А если вернуться к репликам про опенсорс — это хороший проект, по крайней мере из того факта, что внутрь заглядывать не возникало даже необходимости. То, что есть — работает ожидаемо. Того, чего нет — я всё равно понимаю, что мы за это платить не готовы.
И все мои возмущения по сути, сугубо на сравнении с более модными штуками типа mongo — с его веб-панелью, типа cassandra, которая всё сама, типа elasticsearch, который тоже практически всё сам, и так далее — приведите свои примеры.
Oracle это ад администрирования. Хоть за деньги, хоть за бесплатно — «привет из 80-ых».
MSSQL давно не касался, когда касался — всё было в лучших традициях Майкрософта — простые вещи сделать легко, сложные — или невозможно вообще, или не знаю какими усилиями.
У меня в PG, по-большему счету, никаких претензий нет, кроме того, что это в текущем виде, именно что база данных, а не продукт СУБД. Для 90-ых — это круто, для начала 2016 — нууу, ок.
А если вернуться к репликам про опенсорс — это хороший проект, по крайней мере из того факта, что внутрь заглядывать не возникало даже необходимости. То, что есть — работает ожидаемо. Того, чего нет — я всё равно понимаю, что мы за это платить не готовы.
И все мои возмущения по сути, сугубо на сравнении с более модными штуками типа mongo — с его веб-панелью, типа cassandra, которая всё сама, типа elasticsearch, который тоже практически всё сам, и так далее — приведите свои примеры.
Эх не хотел холиварить… а вот и не буду — только одно скажу — мы таки по разную баррикад, вы туда заглядываете, мы же им живём! посему вам вероятно меня не понять, а мне вас…
Если вы живите только ради процесса — то точно не понять.
Если результат вашей «жизни» для вас важен, например в том виде, что пользователи «результата» получают радость использвания хорошего инструмента и решение своих задач с его помощью, то у вас есть шанс.
Представьте, что примерно так же «живу» теми задачами, которые я решаю. И мне от базы данных нужно, что бы «работала и не доставляла забот». Что бы если нужно добавить серверы в кластер, я это сделал за пол дня опытов на модели, а потом с заказчиком договорился о времени, и обновил рабочую систему и был уверен, что всё будет как нужно.
Если нужно порезать архивную таблицу по дате, что бы не писал руками триггеры, боясь ошибиться, а просто сказал «в этом поле дата, нужно нарезать на разделы по годам», мне сказали, сколько примерно времени эта операция займет, и я мог нажать условное «Поехали» в нужное время (когда нагрузка на базу меньше)
Попробуйте просто понять, что я решаю другие задачи, например как правильнее собрать эти самые данные, нужно ли их нормализовать и городить связку таблиц или пока можно просто тупо в одну свалить.
Почему есть несколько статей «как оптимизировать производительность PG», но нет ни одного инструмента в комплекте, который был посмотрел в базу и сказал «чувак, у тебя в системе 8G памяти, а под PG отдано 1G, давай добавим?» и сам бы прописал в конфиге? А через месяц опять «чувак, мы добавили до 6G, но реально больше 5G ни разу не потребовалось, можно уменьшить».
Или как-то иначе «чувак, у тебя в сутки дергается 100500 разных запросов, из них вот эти 5 работают очень медленно и неэффективно — всегда сканируют таблицу целиком, ты уверен, что так и нужно?»
Вы не заметили, что открытые исходники или закрытые — тут вообще не упоминается?
Вот по этим критериям удобства Oracle DB такое-же неудобное и неприятное. И если с PG вроде как в наших масштабах не нужен отдельный DBA, то с Oracle постоянно что-то вылезает, с кучей тонкостей и нюансов, и нужен человек с опытом, который хорошо понимает что вообще происходит и какие рукоятки из миллиона возможных крутить.
Если результат вашей «жизни» для вас важен, например в том виде, что пользователи «результата» получают радость использвания хорошего инструмента и решение своих задач с его помощью, то у вас есть шанс.
Представьте, что примерно так же «живу» теми задачами, которые я решаю. И мне от базы данных нужно, что бы «работала и не доставляла забот». Что бы если нужно добавить серверы в кластер, я это сделал за пол дня опытов на модели, а потом с заказчиком договорился о времени, и обновил рабочую систему и был уверен, что всё будет как нужно.
Если нужно порезать архивную таблицу по дате, что бы не писал руками триггеры, боясь ошибиться, а просто сказал «в этом поле дата, нужно нарезать на разделы по годам», мне сказали, сколько примерно времени эта операция займет, и я мог нажать условное «Поехали» в нужное время (когда нагрузка на базу меньше)
Попробуйте просто понять, что я решаю другие задачи, например как правильнее собрать эти самые данные, нужно ли их нормализовать и городить связку таблиц или пока можно просто тупо в одну свалить.
Почему есть несколько статей «как оптимизировать производительность PG», но нет ни одного инструмента в комплекте, который был посмотрел в базу и сказал «чувак, у тебя в системе 8G памяти, а под PG отдано 1G, давай добавим?» и сам бы прописал в конфиге? А через месяц опять «чувак, мы добавили до 6G, но реально больше 5G ни разу не потребовалось, можно уменьшить».
Или как-то иначе «чувак, у тебя в сутки дергается 100500 разных запросов, из них вот эти 5 работают очень медленно и неэффективно — всегда сканируют таблицу целиком, ты уверен, что так и нужно?»
Вы не заметили, что открытые исходники или закрытые — тут вообще не упоминается?
Вот по этим критериям удобства Oracle DB такое-же неудобное и неприятное. И если с PG вроде как в наших масштабах не нужен отдельный DBA, то с Oracle постоянно что-то вылезает, с кучей тонкостей и нюансов, и нужен человек с опытом, который хорошо понимает что вообще происходит и какие рукоятки из миллиона возможных крутить.
«чувак, у тебя в системе 8G памяти, а под PG отдано 1G, давай добавим?»
А если у вас там ещё веб сервер крутится? Этого не может и не должна знать БД. Вы ей приписываете совершенно не свойственные ей фичи. Этим всем и занимается админ вместе с DBA (или кто то один).
с кучей тонкостей и нюансов, и нужен человек с опытом, который хорошо понимает что вообще происходит и какие рукоятки из миллиона возможных крутить.
Так блин системы сложные! Ну нельзя в пару кликов мышкой собрать ракету для полёта на Марс.
вы реально не понимаете о чем я, жаль.
У меня на календаре 2016 год, уже который год вовсю шагает докер, не говоря уже о том, что уже наверное с десяток лет, как шагают виртуальные машины.
И конечно я полностью с вами согласен, что БД не должна знать о том, крутится ли веб-сервер на этой же машине или нет. Но я не вижу никаких проблем, что бы в комплекте с БД была утилита, которая будет мониторить не только что там внутри БД, а еще и в окружении БД. И если какой-то collectd, вполне может собрать примитивные данные о количестве свободной и используемой памяти, CPU итд — то эта утилита тоже может.
И если есть на хосте свободные ресурсы, и эти ресурсы могут добавить производительности базе (да-да, статистика запросов, и вот это всё) — кто про это сможет узнать? Десяток человек по всему миру, который во всём этом хорошо разбирается? Ну ок, в паре сотен инсталяций с большой нагрузко люди счастливы от использования PG, остальные пробуют с «дефлотными настройками», 10% из них находит статью, что дефолтные настройки «тупо, что бы запустилось», и формулы как посчитать чуть по-лучше, и может быть что-то случайно покрутят. А оставшиеся 90% остаются, мягко говоря «не в восторге».
Пусть я даже ошибаюсь в порядке цифр, и грамотных людей тысячи, а счастливых заказчков сотни тысяч. Но ситуацию это не поменяет, сколько там скачиваний каждой версии?
Я где-то сказал о пера кликов и ракете на Марс?
У меня на календаре 2016 год, уже который год вовсю шагает докер, не говоря уже о том, что уже наверное с десяток лет, как шагают виртуальные машины.
И конечно я полностью с вами согласен, что БД не должна знать о том, крутится ли веб-сервер на этой же машине или нет. Но я не вижу никаких проблем, что бы в комплекте с БД была утилита, которая будет мониторить не только что там внутри БД, а еще и в окружении БД. И если какой-то collectd, вполне может собрать примитивные данные о количестве свободной и используемой памяти, CPU итд — то эта утилита тоже может.
И если есть на хосте свободные ресурсы, и эти ресурсы могут добавить производительности базе (да-да, статистика запросов, и вот это всё) — кто про это сможет узнать? Десяток человек по всему миру, который во всём этом хорошо разбирается? Ну ок, в паре сотен инсталяций с большой нагрузко люди счастливы от использования PG, остальные пробуют с «дефлотными настройками», 10% из них находит статью, что дефолтные настройки «тупо, что бы запустилось», и формулы как посчитать чуть по-лучше, и может быть что-то случайно покрутят. А оставшиеся 90% остаются, мягко говоря «не в восторге».
Пусть я даже ошибаюсь в порядке цифр, и грамотных людей тысячи, а счастливых заказчков сотни тысяч. Но ситуацию это не поменяет, сколько там скачиваний каждой версии?
Я где-то сказал о пера кликов и ракете на Марс?
что бы в комплекте с БД была утилита
У меня на календаре 2016 год, уже который год вовсю шагает докер
Ещё раз: какое отношение эта утилита имеет к БД? Она реально больше к докеру имеет отношение чем к БД.
Если у БД надо узнать какие то параметры или статистику, то она всегда пожалуйста её дать может.
Опять же, если такая система (а не просто утилитка), так нужна то можете написать сами.
PG, остальные пробуют с «дефлотными настройками»
PG тут можно заменить на MySQL, Oracle, IBM DB2 и т.д.
по этому я не понимаю, у вас претензия к отрасли или конкретно к Postgres?
Я где-то сказал о пера кликов и ракете на Марс?
Вы написали про то, что слишком мало супер пупер специалистов во всех тонкостях БД. Я ответил в том ключе, что это неизбежно т.к. сложность текущих БД очень и очень высока.
к БД — никакое, к продукту СУБД — полное.
Если для эффективного использования БД в моей задаче, в моём окруженнии, я вынужден изучать особенности БД, то простите, мне это надоело в 90-ых.
В 2000-ых я смотрю в строну альтернатив, которые меня не заставляют этим всем заморачиваться.
Если вы не прочли в комментариях выше — к PG у меня нет никаких претензий, которые я бы мог подкрепить деньгами на их устранение.
Но ни в одном новом проекте я не буду использовать PG (как и на Oracle, MySQL и всех прочих монстров 90-ых). Я не хочу становиться экспертом в БД, я хочу комфортно решать прикладную задачу.
Сложность использования текущих БД несоизмерима высока, в сравнении с задачами, в решении которых обычно берут их использовать. Наверное в этом отношении лучший баланс был у MySQL.
Если для эффективного использования БД в моей задаче, в моём окруженнии, я вынужден изучать особенности БД, то простите, мне это надоело в 90-ых.
В 2000-ых я смотрю в строну альтернатив, которые меня не заставляют этим всем заморачиваться.
Если вы не прочли в комментариях выше — к PG у меня нет никаких претензий, которые я бы мог подкрепить деньгами на их устранение.
Но ни в одном новом проекте я не буду использовать PG (как и на Oracle, MySQL и всех прочих монстров 90-ых). Я не хочу становиться экспертом в БД, я хочу комфортно решать прикладную задачу.
Сложность использования текущих БД несоизмерима высока, в сравнении с задачами, в решении которых обычно берут их использовать. Наверное в этом отношении лучший баланс был у MySQL.
Но ни в одном новом проекте я не буду использовать PG (как и на Oracle, MySQL и всех прочих монстров 90-ых). Я не хочу становиться экспертом в БД, я хочу комфортно решать прикладную задачу.
Простите конечно, но нету ни одной такой системы которая удовлетворила бы вас.
И все мои возмущения по сути, сугубо на сравнении с более модными штуками типа mongo — с его веб-панелью, типа cassandra, которая всё сама, типа elasticsearch, который тоже практически всё сам, и так далее — приведите свои примеры.
Если вы про это, то поверьте это не решает и 10% проблем таких систем. С той же Mongo под нагрузкой не меньше проблем чем с Postgres (на самом деле куда больше!!!). Или вон недавно сами монговци признались, что если хотите быстрый Mongo то используйте её поверх Postgres. :)
А честные транзакции? А уровни изоляции? Если вам это стало нужно, а у вас Mongo то у вас скорее всего проблема.
MongoDB и многие из этой волны, больше маркетинг чем реально что то ещё. Причём уже очень многие на этом обожглись.
к БД — никакое, к продукту СУБД — полное.
В этом контексте это синонимы. Если вы думаете что под Системой Управлением БД понимается GUI и веб морда для настроек то вы ошибаетесь.
К слову на счёт веб морд: www.heroku.com/postgres такое вас устроит? :)
Простите конечно, но нету ни одной такой системы которая удовлетворила бы вас.
оглянитесь вокруг — есть.
есть достаточно много систем с гораздо более пологой кривой «цена входа»
есть достаточно много систем с гораздо более пологой кривой «цена входа»
Цена входа в этих системах не так важна, как «цена выхода». Лучше сначала немного поучится чем, потом за голову хвататься, пытаясь перекроить архитектуру.
это зависит от того, как устроен ваш бизнес. И зная риски «цены выхода», можно заранее строить бизнес так, что бы эти риски уменьшить.
А сразу вкладывать ресурсы в инструмент, который возможно потребуется заменять — это только если деньги некуда девать.
А сразу вкладывать ресурсы в инструмент, который возможно потребуется заменять — это только если деньги некуда девать.
И всё же, ценна входа у Mongo сопоставима с Postgres. Когда начинаются кластеры или большие нагрузки, понятность, документированность и повторяемость явно за Postgres.
не знаю как вы считаете цену входа, но вот пример из нашей практики: есть у нас небольшой по сложности логики сервис, которому нужно хранилище.
Когда его писали в прошлый раз, и хранилище сделали в таблицах, то получилось 8 таблиц. Не помню уже насколько там всё нормализовано, но вот так оно сейчас работает, много где.
Когда мы решили его переписать, то в монге это одна коллекция. Одна коллекция. Объем хранения небольшой — десятки тысяч записей. Есть у нас «аномально большой» клиент, где 300K документов в этой самой единственной коллекции в монге.
Это же еще небольшие нагрузки?
Идем дальше, мы в новой версии добавили еще одно хранение (старая версия сервиса работала как труба). Вот у этого аномального клиента там 4.7М записей, во второй коллекции.
В принципе, если сейчас подумать как бы добавлять в прошлую версию это жесамое, можно было бы в одну таблицу всё засунуть, аналогично. Хотя по хорошему, есть смысл нормализовать, и разложить на три таблицы минимум. Но в самой большой, было бы аналогично 4.7M записей.
То есть в нереляционной модели, уже меньше расходы на проектирование и реализацию.
Теперь мой либимое: монга у нас ставится инсталятором, вся от-и-до. Потому, что это тупо один mongod.exe, который даже сам виндовой службой регистрируется. Вкладывание одного исполняемого файла в пакет, заняло ну пару часов.
Я знаю, что можно и PG вложить внутрь и устанавливать автоматически, но сразу на винде начинаются всякие пляски с бубном — где-то ему не нравится русские буквы в «C:\Пользователи\», где-то оно не может получить админские права, где-то еще что-то, в зависимости от версии виндовса, и его русскости. Регулярно инженер при установке какие-то нюансы выгребает.
Что бы всё это побороть, думаю дня три нужно, не меньше, а скорее всего неделю. Поскольку у нас не тысячи установок, и «один раз поставил, работает долго», мы это всё не дожимаем до полной автоматики. Но очень хорошо понимаем, что если вдруг у нас будет рост количества установок, то для PG сразу нужно будет вложить время на разработку, плюс сразу заложить время на поддержку (у кого-то столкнулись, например, с грамотными админами, у них на сервере диска С нет как класса).
Для монги — заложено время на поддержку, но в разы меньше.
Когда начинаются кластеры, то всех «с монгой», я отправлю на их родной сервис, где за время триального периода можно собрать и запустить кластер, а потом снять его с мониторинга. До недавнего времени у сервиса был бесплатный вариант, с какими-то ограничениями по хостам, или группам. Если кто-то этим собирается заниматься регулярно — есть нормальный бесплатный обучающий курс, где рассказывают как собирать кластеры. С приличными лекциями и домашними заданиями.
Насколько я понимаю у той же Кассандры такое вообще из коробки в комплекте.
У того же ElasticSearch сборка кластера — максимум в конфиге написать имена хостов, если они сами друг друга бродкастами не найдут в одном сегменте сети.
Когда его писали в прошлый раз, и хранилище сделали в таблицах, то получилось 8 таблиц. Не помню уже насколько там всё нормализовано, но вот так оно сейчас работает, много где.
Когда мы решили его переписать, то в монге это одна коллекция. Одна коллекция. Объем хранения небольшой — десятки тысяч записей. Есть у нас «аномально большой» клиент, где 300K документов в этой самой единственной коллекции в монге.
Это же еще небольшие нагрузки?
Идем дальше, мы в новой версии добавили еще одно хранение (старая версия сервиса работала как труба). Вот у этого аномального клиента там 4.7М записей, во второй коллекции.
В принципе, если сейчас подумать как бы добавлять в прошлую версию это жесамое, можно было бы в одну таблицу всё засунуть, аналогично. Хотя по хорошему, есть смысл нормализовать, и разложить на три таблицы минимум. Но в самой большой, было бы аналогично 4.7M записей.
То есть в нереляционной модели, уже меньше расходы на проектирование и реализацию.
Теперь мой либимое: монга у нас ставится инсталятором, вся от-и-до. Потому, что это тупо один mongod.exe, который даже сам виндовой службой регистрируется. Вкладывание одного исполняемого файла в пакет, заняло ну пару часов.
Я знаю, что можно и PG вложить внутрь и устанавливать автоматически, но сразу на винде начинаются всякие пляски с бубном — где-то ему не нравится русские буквы в «C:\Пользователи\», где-то оно не может получить админские права, где-то еще что-то, в зависимости от версии виндовса, и его русскости. Регулярно инженер при установке какие-то нюансы выгребает.
Что бы всё это побороть, думаю дня три нужно, не меньше, а скорее всего неделю. Поскольку у нас не тысячи установок, и «один раз поставил, работает долго», мы это всё не дожимаем до полной автоматики. Но очень хорошо понимаем, что если вдруг у нас будет рост количества установок, то для PG сразу нужно будет вложить время на разработку, плюс сразу заложить время на поддержку (у кого-то столкнулись, например, с грамотными админами, у них на сервере диска С нет как класса).
Для монги — заложено время на поддержку, но в разы меньше.
Когда начинаются кластеры, то всех «с монгой», я отправлю на их родной сервис, где за время триального периода можно собрать и запустить кластер, а потом снять его с мониторинга. До недавнего времени у сервиса был бесплатный вариант, с какими-то ограничениями по хостам, или группам. Если кто-то этим собирается заниматься регулярно — есть нормальный бесплатный обучающий курс, где рассказывают как собирать кластеры. С приличными лекциями и домашними заданиями.
Насколько я понимаю у той же Кассандры такое вообще из коробки в комплекте.
У того же ElasticSearch сборка кластера — максимум в конфиге написать имена хостов, если они сами друг друга бродкастами не найдут в одном сегменте сети.
Теперь мой либимое: монга у нас ставится инсталятором, вся от-и-до. Потому, что это тупо один mongod.exe, который даже сам виндовой службой регистрируется. Вкладывание одного исполняемого файла в пакет, заняло ну пару часов.
Я знаю, что можно и PG вложить внутрь и устанавливать автоматически, но сразу на винде начинаются всякие пляски с бубном — где-то ему не нравится русские буквы в «C:\Пользователи\», где-то оно не может получить админские права, где-то еще что-то, в зависимости от версии виндовса, и его русскости. Регулярно инженер при установке какие-то нюансы выгребает.
Простите, но всё то, что я писал выше было серверное применение СУБД где 80% Unix. То, что вы пишете выше, это Embended использование. И тут MongoDB наверное не плохо смотрится на фоне SQLite или MySQLEmbended.
Ну и для справедливости, в 9.5 многие выше указанные ошибки в Postgres устранены.
Когда мы решили его переписать, то в монге это одна коллекция.
Что вам мешает сделать таблицу с одним столбцом JSONB?
Я к стати начал понимаю где вы работаете…
На счёт кластеров: мне кажется их сравнивать как тёплое с мягким, у того, что вы привели в пример, нету ни ACID ни MVCС, не очень честное сравнение.
ЗЫ простите, что читаете весь этот диалог, но он всё же интересный. :)
То есть небольшие приложения, масштаба SoHo изначально пролетают, да?
Да-да, они сейчас всё в SQLite хранят, а если это MS-Solutons, то MS SQL Embedded который до каких-то там размеров бесплатен и (сюрприз!) очень легко деплоится.
Если небольшие приложения откинули как не целевой рынок, то опять смотрим на горизонтальное масштабирование, которое разворачивается из web-интерфейса в SaaS. Без разницы какая платформа. «Руками» нужно установить только агента этого самого SaaS.
Оно даже на ходу обновит версию. Я проверил — база при этом продолжает работать, конечно если кластер собрать с достаточным уровнем избыточности по репликам.
Вы попробуйте, это реально прикольно, я разок по-троллил наших специалистов по ораклу, говорю «о, новая версия монги, идите посмотрите как кластер сам обновляется».
Вы бы видели их лица, особенно тех, кто не по наслышке знает, как RAC поднимать.
То, что по столбцу JSON, я не могу фильтрануть «дай мне документы у которых есть some.subdocument.field = „some value“»
Мне не нужно всё делать своими руками, не нужно погружаться в инструмент.
Там, где люди грамотно подошли к использованию инструмента — данные номализованы и пачка таблиц.
Первый коммит исходников в версии с монгой был более 7 лет назад.
Не важно где я работаю — для любого нового проекта без четких требований монга у нас по-умолчанию. Ситуация очень похоже на то, как когда-то для любого сайтика был MySQL.
И когда уже модель софта приобретет хоть какие-то осязаемые формы, можно набрасывать тестовые данные, измерять производительность, тестировать надежность, и думать как быть дальше — взлетит это всё в таком виде или нет.
Я вообще не вижу смысла сейчас, не имея четких требования, из которых следует «нужна реляционка, которая удовлетворит таким-то показателям производительности на таком-то объеме данных и примерно таком железе», начинать что-либо на RDBMS.
Не знаю, в каком проценте каких задач нужны ACID, MVCC, простите. Мы обходимся. Кстати, а не получится ли ACID «как бы сам собой», учитывая, что вместо пачки таблиц, у нас одна коллекция и один документ с данными?
Есть подозрение, что вот этот весь маркетинг вокруг NoSQL, он «ответная реакция» не то, что ценность ACID, MVCC и прочих базвордов сильно была преувеличена.
Видимо, аналогичным маркетингом со стороны СУБД-монстров прошлых лет ;)
Да-да, они сейчас всё в SQLite хранят, а если это MS-Solutons, то MS SQL Embedded который до каких-то там размеров бесплатен и (сюрприз!) очень легко деплоится.
Если небольшие приложения откинули как не целевой рынок, то опять смотрим на горизонтальное масштабирование, которое разворачивается из web-интерфейса в SaaS. Без разницы какая платформа. «Руками» нужно установить только агента этого самого SaaS.
Оно даже на ходу обновит версию. Я проверил — база при этом продолжает работать, конечно если кластер собрать с достаточным уровнем избыточности по репликам.
Вы попробуйте, это реально прикольно, я разок по-троллил наших специалистов по ораклу, говорю «о, новая версия монги, идите посмотрите как кластер сам обновляется».
Вы бы видели их лица, особенно тех, кто не по наслышке знает, как RAC поднимать.
Что вам мешает сделать таблицу с одним столбцом JSONB?
То, что по столбцу JSON, я не могу фильтрануть «дай мне документы у которых есть some.subdocument.field = „some value“»
Мне не нужно всё делать своими руками, не нужно погружаться в инструмент.
Там, где люди грамотно подошли к использованию инструмента — данные номализованы и пачка таблиц.
Первый коммит исходников в версии с монгой был более 7 лет назад.
Не важно где я работаю — для любого нового проекта без четких требований монга у нас по-умолчанию. Ситуация очень похоже на то, как когда-то для любого сайтика был MySQL.
И когда уже модель софта приобретет хоть какие-то осязаемые формы, можно набрасывать тестовые данные, измерять производительность, тестировать надежность, и думать как быть дальше — взлетит это всё в таком виде или нет.
Я вообще не вижу смысла сейчас, не имея четких требования, из которых следует «нужна реляционка, которая удовлетворит таким-то показателям производительности на таком-то объеме данных и примерно таком железе», начинать что-либо на RDBMS.
Не знаю, в каком проценте каких задач нужны ACID, MVCC, простите. Мы обходимся. Кстати, а не получится ли ACID «как бы сам собой», учитывая, что вместо пачки таблиц, у нас одна коллекция и один документ с данными?
Есть подозрение, что вот этот весь маркетинг вокруг NoSQL, он «ответная реакция» не то, что ценность ACID, MVCC и прочих базвордов сильно была преувеличена.
Видимо, аналогичным маркетингом со стороны СУБД-монстров прошлых лет ;)
То есть небольшие приложения, масштаба SoHo изначально пролетают, да?
Если они не клиент/серверные и на Windows то Postgres думаю не для них.
То, что по столбцу JSON, я не могу фильтрануть «дай мне документы у которых есть some.subdocument.field = „some value“»
Мне не нужно всё делать своими руками, не нужно погружаться в инструмент.
Почему не можете? Можете! И даже индексы на это накинуть. :) Вы просто плохо знаете NoSQL возможности Postgres.
Не знаю, в каком проценте каких задач нужны ACID, MVCC, простите.
Везде где нельзя потерять данные, или где можно потерять консистентность.
ценность ACID, MVCC и прочих базвордов сильно была преувеличена
Тут всё просто:
1. Если пользователь послал сообщение любовное подруге, а система сказала ОК, и тут сервер падает. Вот с Postgres после поднятия БД (если физически данные не похерились) это сообщение будет там лежать. В ваших системах мы можем его потерять. А если это денежный перевод? Короче если вам это не критично, для вас это не самые важные слова.
2. Несколько пользователей решили кинуть деньги на один счёт, если не делать блокировок, итоговая сумма может быть иной. т.е. если вам ненужны транзакции…
Насколько мне известно, не так много use cases где на выше указанные проблемы можно было бы закрыть глаза.
Без разницы какая платформа. «Руками» нужно установить только агента этого самого SaaS.
Я привёл в пример Heroku.
конечно приложения клиент-серверные. Но небольшие, с точки зрения объемов данных, и развесистости структур данных.
Я вообще не знаю возможностей JSON в PG, потому, что когда мы начинали, никаких таких не было, и даже когда мы запустили в продакшн, тоже. Опять-же, JSON — это «всего лишь сопособ». У нас вообще всё по жизни XML (тяжелые наследия стандартов рожденных в кровавом энтерпрайзе), и когда мы смотрели, JSON вообще никак не участвовал в выборе. Но очень не хотелось документы каждый раз разбирать, при получении, и собирать перед тем, как отдать.
давайте на минуточку, вспомним, что все эти возможности потерять, они возникают при конкурентном доступе, а скорее всего, при высоко конкурентном доступе к данным.
Вокруг меня, 99% софта — «трехзвенная архитектура» — клиент напрямую с базой не общается. Более того, app-server, в 99% ходит в базу через ORM, и только в совсем тяжелых случаях, где-то есть какие-то curcor.execute(someSqlCode). Это значит, что у нас trade-of — заряжаем по полной в стандартную машинку задачу, (описание предметной области, нормализация, ORM), или заряжаем ту же задачу в другую машинку, модную-хипстерскую, где «документы», «коллекции», и так далее.
отлично, то есть RDBMS рулят и бибикают вокруг денег, и прочих сущностей строгого учета. Ниваропс. Какой процент таких задач?
хороший пример, но немного «не в тему».
Попробую более детально описать, как я делаю кластеры монги:
* на своих серверах устанавливаю агент монговского SaaaS
* даю этому агенту APIkey
* они все идут в SaaS
* там, через web-ui, сочиняю кластер, нужной мне конфигурации
* жду какое-то время, получаю готовый кластер
и если не нужно его автоматически обновлять и как-то комфортно мониторить, расширять и так далее — на этом использование SaaS можно завершить, продолжить использование кластера.
Если нужно — с недавнего времени это всё стало дорого, но я подозреваю, что за пол года год, появятся бесплатные замены. Потому, что собрать из монги кластер, это довольно простая работа, достаточно знать,
* какие демоны на каких хостах запускать
* в каком порядке
* какой конфиг им каждому загрузить в базу /admin
Я вообще не знаю возможностей JSON в PG, потому, что когда мы начинали, никаких таких не было, и даже когда мы запустили в продакшн, тоже. Опять-же, JSON — это «всего лишь сопособ». У нас вообще всё по жизни XML (тяжелые наследия стандартов рожденных в кровавом энтерпрайзе), и когда мы смотрели, JSON вообще никак не участвовал в выборе. Но очень не хотелось документы каждый раз разбирать, при получении, и собирать перед тем, как отдать.
Везде где нельзя потерять данные, или где можно потерять консистентность.
давайте на минуточку, вспомним, что все эти возможности потерять, они возникают при конкурентном доступе, а скорее всего, при высоко конкурентном доступе к данным.
Вокруг меня, 99% софта — «трехзвенная архитектура» — клиент напрямую с базой не общается. Более того, app-server, в 99% ходит в базу через ORM, и только в совсем тяжелых случаях, где-то есть какие-то curcor.execute(someSqlCode). Это значит, что у нас trade-of — заряжаем по полной в стандартную машинку задачу, (описание предметной области, нормализация, ORM), или заряжаем ту же задачу в другую машинку, модную-хипстерскую, где «документы», «коллекции», и так далее.
А если это денежный перевод?
отлично, то есть RDBMS рулят и бибикают вокруг денег, и прочих сущностей строгого учета. Ниваропс. Какой процент таких задач?
Я привёл в пример Heroku.
хороший пример, но немного «не в тему».
Попробую более детально описать, как я делаю кластеры монги:
* на своих серверах устанавливаю агент монговского SaaaS
* даю этому агенту APIkey
* они все идут в SaaS
* там, через web-ui, сочиняю кластер, нужной мне конфигурации
* жду какое-то время, получаю готовый кластер
и если не нужно его автоматически обновлять и как-то комфортно мониторить, расширять и так далее — на этом использование SaaS можно завершить, продолжить использование кластера.
Если нужно — с недавнего времени это всё стало дорого, но я подозреваю, что за пол года год, появятся бесплатные замены. Потому, что собрать из монги кластер, это довольно простая работа, достаточно знать,
* какие демоны на каких хостах запускать
* в каком порядке
* какой конфиг им каждому загрузить в базу /admin
Я вообще не знаю возможностей JSON в PG, потому, что когда мы начинали, никаких таких не было, и даже когда мы запустили в продакшн, тоже.
Я сейчас говорю в разрезе выходя 9.5, а не про 10 лет назад. Как я выше писал, сами монговци предлагают работать поверх Postgres. ;)
Вокруг меня, 99% софта — «трехзвенная архитектура» — клиент напрямую с базой не общается.
Это не отменяет вопроса надёжности и консистентности. Кроме того давайте не путать, напрямую юзер не стучится к БД, но у БД как были клиенты так и есть. :) Кроме того, в том же вебе иначе и не бывает, всегда есть некий программный сервер который обслуживает запросы пользователей и в свою очередь он стучится к БД. Но замечу ещё раз, это никак не влияет на то, что я сказал выше. ORM вообще параллельна всей нашей дискуссии.
отлично, то есть RDBMS рулят и бибикают вокруг денег, и прочих сущностей строгого учета. Ниваропс. Какой процент таких задач?
Ещё раз, они рулят везде где вам будет дорого потерять данные, а это не меньше 90% случаев.
т.е. к примеру у юзера вылезла старая аватарка может и не страшно, а если вы потеряли его сообщение уже может быть очень плохо.
хороший пример, но немного «не в тему».
Мне всё же кажется, ваш пример крайне локальный и редкий, а вы пытаетесь его натянуть на все случаи работы с БД.
надежность и консистентность можно «подкрепить» на уровне приложения, если известно, что у БД с этим не очень хорошо. Это всегда trade-of
Конечно у нас локальный и редкий, как и в подавляющем случае в RDBMS, их используют «потому, что умеют», а не потому, что это реально дает какие-то плюсы. Но это время закончилось с началом бума NoSQL.
Конечно у нас локальный и редкий, как и в подавляющем случае в RDBMS, их используют «потому, что умеют», а не потому, что это реально дает какие-то плюсы. Но это время закончилось с началом бума NoSQL.
То, что по столбцу JSON, я не могу фильтрануть «дай мне документы у которых есть some.subdocument.field = „some value“»
А я могу q:
select doc from collection1 where doc -> 'subdocument' ->> 'field' = 'some value'
К сожалению люди которые пилят БД как правило делают именно БД
Зря вы так думаете. Просто есть:
1. Не такой большой спрос на эти фичи.
2. Не все фичи легко реализовать исходя из текущей архитектуры. К примеру для UPSERT пришлось вводить новый тип блокировки (Postgres очень строгий MVCC).
меня даже более простой интересует — партиционирование таблиц
Вот прям сейчас это пилится, уже есть хорошие результаты, надеюсь в 9.6 будет. Хотя главная там задача избавится от оверхеда и сделать работу с 10000 партициями без проседания производительности (сейчас в postgres уже на 100 есть траблы).
по крайней мере вокруг меня разработка сдвигается в сторону от реляционных баз. Данные из реальной жизни становятся сложнее структурно, запихивание их в таблицы занимает всё больше труда. При этом альтернативные решения, всякие такие фишки уже дают.
У нас малюпусенькая «проблема» — есть таблицы, в которых архив данных, где ничего не удаляется. Нам бы хватило «нарезка по годам». На 100 разделах, говорите проблема? У самого старого клиента — 11 лет архив. На 30 разделах нет проблем?
Какие есть причины, не выпускать фичу, которая хорошо работает на малых объемах?
У нас малюпусенькая «проблема» — есть таблицы, в которых архив данных, где ничего не удаляется. Нам бы хватило «нарезка по годам». На 100 разделах, говорите проблема? У самого старого клиента — 11 лет архив. На 30 разделах нет проблем?
Какие есть причины, не выпускать фичу, которая хорошо работает на малых объемах?
по крайней мере вокруг меня разработка сдвигается в сторону от реляционных баз. Данные из реальной жизни становятся сложнее структурно, запихивание их в таблицы занимает всё больше труда. При этом альтернативные решения, всякие такие фишки уже дают.
Именно по этому в Postgres есть JSON/JOSNB и в 9.5 появился json_set.
Какие есть причины, не выпускать фичу, которая хорошо работает на малых объемах?
Не очень понимаю ваш вопрос. Тут отчасти как с UPSERT т.е. партицирования в Postgres нету, оно эмулируется через наследование таблиц. т.е. это достаточно сложный вопрос. Кроме того спрос (от крупных фирм готовых платить) есть именно на партицирование тысяч таблиц.
Можно увидеть ссылку на «5% времени» по BRIN индексам? Или тут ошибка и имелся ввиду размер?
Ну судя по этому wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.5#BRIN_Indexes имеется в виду скорее всего время (ибо в примере не указан размер BTREE индекса, только BRIN, хотя косвенно можно решить, что индекса там где-то на 3ГБ).
BRIN-индексы хранят только минимальное и максимальное значение в блоке строк (по умолчанию в блоке 128 строк) и имеют смысл только на огромных таблицах, в которых данные сами по себе упорядочены (логи, всяческая телеметрия и прочее). И ускорение они дают именно за счёт своего крошечного размера (там, где BTree будет занимать десятки гигабайт, BRIN займёт единицы мегабайт). Задача BRIN — отсеять как можно больше физических страниц от последующего сканирования с перепроверкой условия (Recheck Cond в выводе EXPLAIN), т.е. уменьшить количество IO-операций. Зато это, наверное, как раз тот самый индекс, который можно вешать почти на все колонки без разбору (занимает мало места, маленькие накладные расходы).
Там в примерах размеры всех индексов указаны, кстати.
Там в примерах размеры всех индексов указаны, кстати.
«For example, tables containing logging data with billions of rows could be indexed and searched in 5% of the time required by standard BTree indexes.»
«Например, таблицы, содержащие данные системных журналов с миллиардами строк, могут быть проиндексированы и просканированы всего за 5% от времени, которое требуется для стандартных BTree-индексов.»
www.postgresql.org/about/news/1636
«Например, таблицы, содержащие данные системных журналов с миллиардами строк, могут быть проиндексированы и просканированы всего за 5% от времени, которое требуется для стандартных BTree-индексов.»
www.postgresql.org/about/news/1636
В ранних обзорах (1-2 годичной давности) всегда явно указывалось, что BTREE индексы быстрее (причем, в разы), а BRIN выигрывают только по размеру и скорости создания (например, вот бенч). Интересно, поменялось ли это после релиза.
Нет не поменялось. У BTree есть проблемы когда записей ооочень много то добавление нового элемента становится очень затратным.
Если у вас огромная таблица и вам иногда хочется по ней искать быстрее чем SeqScan то BRIN хороший выбор.
ЗЫ была надежда, что COLA отчасти решит это… но увы. Сейчас правда идут подвижки к улучшению самого BTree, возможно которые приведут к ненужности GIN.
Если у вас огромная таблица и вам иногда хочется по ней искать быстрее чем SeqScan то BRIN хороший выбор.
ЗЫ была надежда, что COLA отчасти решит это… но увы. Сейчас правда идут подвижки к улучшению самого BTree, возможно которые приведут к ненужности GIN.
Отлично! Я джва года ждал! Долой тучу хранимых процедур, да здравствует UPSERT!
присоединяюсь
Да UPSERT действительно киллер фича. узнал от Mysql-щика.
и тут даже лучше реализовано, чем REPLACE в MySQL, потому как REPLACE делает сперва DELETE перед INSERT, а не UPDATE вместо INSERT при нахождении записи.
так update в pg это и есть всегда delete + insert
тогда непонятно, почему его назвали UPSERT, а не REPLACE и пишут, что происходит UPDATE, когда происходит DELETE+INSERT
Я бы не стал тут так однозначно: если MVCC решит, что старая (сейчас обновляемая) версия row никого больше не интересует, типа нет открытых транзакций, или строгий уровень изоляции или локовая модель (transaction isolation, explicit locking), то насколько помню она обновится на лету без новой строчки (и вакуумов опосля и иже с ними).
Например, row-level локи однозначно обновят строчку на лету.
Например, row-level локи однозначно обновят строчку на лету.
в мускуле если не нужен
REPLACE есть INSERT...ON DUPLICATE KEY UPDATE, но постгресовый UPSERT действительно намного удобнее синтаксически в этом плане…marks, спасибо за перевод пресс-релиза, но антиспасибо за его сокращение с выкидыванием кучи полезной информации. Официальный (и полный!) пресс-релиз на русском можно прочитать здесь: postgresmen.ru/postgresql-9.5 и в нём же есть куча ссылок для дальнейшего изучения.
Честно говоря, не видел русского пресс-релиза. Добавил из него информацию тоже, спасибо.
извините за привередничество, но можно пруф на официальность? :)
Таковым его назвали в фейсбук-группе «PostgreSQL» в России» www.facebook.com/groups/postgresql. А там в основном новости пишут разработчики постгреса, посему я так его и назвал так же.
Вот не понятно только когда они пофиксят ошибки на виндовых сборках: LIKE поиск (регистро зависим), работа с типом поля blob (не все байты обрабатываются), и т.д…
в sql стандарте же есть Merge. Крупняк — Oracle и MSSQL реализовали Merge. Почему PG пошел на upsert ?? Ориентируются на mysql?
а MERGE это разве не слияние двух таблиц?
Слияние. Но им вполне можно пользоваться как UPSERT'ом
Скрытый текст
MERGE INTO Sales.SalesReason AS Target
USING (VALUES ('Recommendation','Other'))
AS Source (NewName, NewReasonType)
ON Target.Name = Source.NewName
WHEN MATCHED THEN
UPDATE SET ReasonType = Source.NewReasonType
WHEN NOT MATCHED THEN
INSERT (Name, ReasonType) VALUES (NewName, NewReasonType)
Постгресовцев не устроило то, что MERGE не concurrent-safe (в стандарте SQL это точно не описано, реализации в этом плане у всех разные). Поэтому реализовали своё решение, которое даёт больше гарантий безопасности при конкурентном доступе к данным. Читать тут: wiki.postgresql.org/wiki/UPSERT
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел PostgreSQL 9.5: UPSERT, RLS и Big Data