Сегодня PostgreSQL Global Development Group объявила о выходе PostgreSQL 9.5. Среди прочих нововведений можно отметить функцию UPSERT, безопасность на уровне строк (Row Level Security, RLS) и несколько функций работы с Big Data. По мнению разработчиков, новые функции делают PostgreSQL лучшим вариантом среди всех возможных для стартапов, больших корпораций, правительственных организаций.
Более подробно о новых функциях — под катом.
UPSERT
Наиболее востребованная функция среди разработчиков приложений, UPSERT является сокращением для «INSERT, ON CONFLICT UPDATE». Новая возможность позволяет обработать ситуацию невозможности добавления данных через «INSERT», например, из-за нарушения условий уникальности или недопустимости значения одного из полей, и вместо вывода ошибки игнорировать выполнение оператора или изменить связанные с ключевым полем данные (т.е. если запись уже существует, вместо INSERT выполнить UPDATE).
По словам представителей команды, UPSERT упрощает разработку веб и мобильных приложений. Условие ON CONFLICT позволяет игнорировать новые данные, или обновлять различные столбцы или связи таким образом, чтобы осуществлялась поддержка ETL (Extract, Transform, Load) наборов компиляторов для загрузки массивов данных. Новая функция полностью совместима со всеми другими возможностями PostgreSQL, включая Logical Replication.
Row-Level Security (RLS)
Эта функция — результат работы продолжительностью в пять лет. RLS предоставляет возможность создания политик безопасности, которые ограничивают доступ пользователям к информации в БД. Политики безопасности позволяют либо «закрыть» информацию полностью или частично, либо разрешить выполнение определенных действий с информацией.
Big Data
Здесь разработчики добавили сразу несколько новых функций, включая Block Range Indexes (BRIN), обеспечивающий более быстрый поиск некоторых типов данных. На поиск таких данных, по заявлению представителей команды, будет уходить всего 5% времени, требуемого для осуществления поиска B-tree.
BRIN-индексы. Этот новый тип индексов позволяет создавать крошечные, но эффективные индексы для очень больших таблиц, данные в которых «естественным образом упорядочены». Например, таблицы, содержащие данные системных журналов с миллиардами строк, могут быть проиндексированы и просканированы всего за 5% от времени, которое требуется для стандартных BTree-индексов.
Ускоренная сортировка. Теперь PostgreSQL сортирует текстовые данные и данные типа NUMERIC быстрее, используя алгоритм «сокращенных ключей». Это ускоряет некоторые запросы, требующие сортировки больших объёмов данных, от 2-х до 12-и раз и может ускорить создание индексов до 20-и раз.
CUBE, ROLLUP и GROUPING SETS. Эти новые предложения стандартного языка SQL позволяют пользователям создавать отчёты с несколькими уровнями подведения итогов в одном-единственном запросе. Предложение CUBE также позволяет тесно интегрировать PostgreSQL с бо?льшим числом инструментов создания OLAP-отчётов (Online Analytic Processing) — таких как Tableau.
Адаптеры внешних данных (Foreign Data Wrappers, FDW). Этот функционал и ранее позволял использовать PostgreSQL как среду для запросов к другим «Big Data»-системам — например, Hadoop и Cassandra. В версии 9.5 добавлены команда IMPORT FOREIGN SCHEMA и JOIN-вытеснение (JOIN pushdown), что делает запросы к внешним базам данных как более лёгкими в установке, так и более эффективными.
TABLESAMPLE. Это SQL-предложение позволяет быстро получить статистическую выборку для огромной таблицы без необходимости ресурсоёмкой сортировки.
В целом, в версии 9.5 много нового, реально полезного для разработчиков. При этом стоит помнить, что при обновлении некоторых старых БД могут возникнуть проблемы, об этом стоит помнить.
Еще более подробная информация о нововведениях в версии 9.5 (Wiki от разработчиков) можно доступна здесь или здесь (русский пресс-релиз).
Комментарии (65)
robert_ayrapetyan
08.01.2016 04:46+1Можно увидеть ссылку на «5% времени» по BRIN индексам? Или тут ошибка и имелся ввиду размер?
alekciy
08.01.2016 10:04Ну судя по этому wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.5#BRIN_Indexes имеется в виду скорее всего время (ибо в примере не указан размер BTREE индекса, только BRIN, хотя косвенно можно решить, что индекса там где-то на 3ГБ).
Envek
08.01.2016 10:22+1BRIN-индексы хранят только минимальное и максимальное значение в блоке строк (по умолчанию в блоке 128 строк) и имеют смысл только на огромных таблицах, в которых данные сами по себе упорядочены (логи, всяческая телеметрия и прочее). И ускорение они дают именно за счёт своего крошечного размера (там, где BTree будет занимать десятки гигабайт, BRIN займёт единицы мегабайт). Задача BRIN — отсеять как можно больше физических страниц от последующего сканирования с перепроверкой условия (Recheck Cond в выводе EXPLAIN), т.е. уменьшить количество IO-операций. Зато это, наверное, как раз тот самый индекс, который можно вешать почти на все колонки без разбору (занимает мало места, маленькие накладные расходы).
Там в примерах размеры всех индексов указаны, кстати.
Shannon
08.01.2016 13:32«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/1636robert_ayrapetyan
08.01.2016 18:36В ранних обзорах (1-2 годичной давности) всегда явно указывалось, что BTREE индексы быстрее (причем, в разы), а BRIN выигрывают только по размеру и скорости создания (например, вот бенч). Интересно, поменялось ли это после релиза.
stalkerg
09.01.2016 14:17+1Нет не поменялось. У BTree есть проблемы когда записей ооочень много то добавление нового элемента становится очень затратным.
Если у вас огромная таблица и вам иногда хочется по ней искать быстрее чем SeqScan то BRIN хороший выбор.
ЗЫ была надежда, что COLA отчасти решит это… но увы. Сейчас правда идут подвижки к улучшению самого BTree, возможно которые приведут к ненужности GIN.
PHmaster
08.01.2016 04:53+6Отлично! Я джва года ждал! Долой тучу хранимых процедур, да здравствует UPSERT!
greabock
08.01.2016 06:31присоединяюсь
SOLON7
08.01.2016 09:31+2Да UPSERT действительно киллер фича. узнал от Mysql-щика.
Borz
08.01.2016 10:22и тут даже лучше реализовано, чем REPLACE в MySQL, потому как REPLACE делает сперва DELETE перед INSERT, а не UPDATE вместо INSERT при нахождении записи.
neolink
08.01.2016 11:59так update в pg это и есть всегда delete + insert
Borz
08.01.2016 12:27тогда непонятно, почему его назвали UPSERT, а не REPLACE и пишут, что происходит UPDATE, когда происходит DELETE+INSERT
sebres
08.01.2016 12:59Я бы не стал тут так однозначно: если MVCC решит, что старая (сейчас обновляемая) версия row никого больше не интересует, типа нет открытых транзакций, или строгий уровень изоляции или локовая модель (transaction isolation, explicit locking), то насколько помню она обновится на лету без новой строчки (и вакуумов опосля и иже с ними).
Например, row-level локи однозначно обновят строчку на лету.stalkerg
09.01.2016 14:07Старый тупл никогда не обновляется, создаётся всегда новый с новым TID, xmin, xmax. Другое дело, что оно может упасть в ту же страницу памяти.
Ну и не забываем, что при работе с индексами там немного иначе может всё отработать (т.е. логика этого процесса для индекса и хипа отделена).
sebres
08.01.2016 12:44+4в мускуле если не нужен
REPLACEестьINSERT...ON DUPLICATE KEY UPDATE, но постгресовыйUPSERTдействительно намного удобнее синтаксически в этом плане…
Envek
08.01.2016 10:14+8marks, спасибо за перевод пресс-релиза, но антиспасибо за его сокращение с выкидыванием кучи полезной информации. Официальный (и полный!) пресс-релиз на русском можно прочитать здесь: postgresmen.ru/postgresql-9.5 и в нём же есть куча ссылок для дальнейшего изучения.
marks
08.01.2016 11:55Честно говоря, не видел русского пресс-релиза. Добавил из него информацию тоже, спасибо.
mva
08.01.2016 14:29извините за привередничество, но можно пруф на официальность? :)
Envek
08.01.2016 23:46Таковым его назвали в фейсбук-группе «PostgreSQL» в России» www.facebook.com/groups/postgresql. А там в основном новости пишут разработчики постгреса, посему я так его и назвал так же.
Rathil
08.01.2016 13:14Вот не понятно только когда они пофиксят ошибки на виндовых сборках: LIKE поиск (регистро зависим), работа с типом поля blob (не все байты обрабатываются), и т.д…
robert_ayrapetyan
08.01.2016 22:42+1А что не так с LIKE? В Postgres для регистро-независимого есть ILIKE…
Ivan22
14.01.2016 15:05-2в sql стандарте же есть Merge. Крупняк — Oracle и MSSQL реализовали Merge. Почему PG пошел на upsert ?? Ориентируются на mysql?
Borz
14.01.2016 15:15+2а MERGE это разве не слияние двух таблиц?
JeStoneDev
14.01.2016 15:42Слияние. Но им вполне можно пользоваться как 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)Envek
15.01.2016 11:28+2Постгресовцев не устроило то, что MERGE не concurrent-safe (в стандарте SQL это точно не описано, реализации в этом плане у всех разные). Поэтому реализовали своё решение, которое даёт больше гарантий безопасности при конкурентном доступе к данным. Читать тут: wiki.postgresql.org/wiki/UPSERT
DmitryKoterov
Все новые и новые фичи добавляются… Но когда же допилят репликацию до «коробочного» состояния «настроил-и-забыл», как в Монге или даже лучше? Уже ж столько лет прошло, и вещь это совершенно необходимая. А воз и ныне там — правим файлики руками и выполняем рукодельные команды в командной строке только для того, чтобы сделать свичовер/фэйловер или добавить новую машину.
bormotov
если это мало кому нужно, чего его пилить?
меня даже более простой интересует — партиционирование таблиц, тоже не очень приятно руками делать, и тоже «вроде бы как» не должно быть сильно трудно автоматизировать. Но видимо, кому нужно — те руками делают, работа ведь редкая, может быть вообще одноразовая.
rshadow
К сожалению люди которые пилят БД как правило делают именно БД, а не инструмент для других людей. Они далеки от потребностей проектов, а тем более проектов высоконагруженных. Им интересней теоритические фичи. А необходимый UPSERT который есть у всех пилится годами. Это печально.
Это конечно не отменяет что постгря лучшее из того что есть =)
bormotov
почему «к сожалению»? Всё правильно, до тех пор, пока мы не говорим «БД = продукт».
Если у нас БД, это такая чудо технология — нивапрос.
С другой стороны, очевидно же, люди которые пилят, на что-то живут, откуда-то получают деньги за свою работу? И елси те, кто готов платить деньги «за БД», не строят кластеры, не разбивают таблицы на части, то это и не пилят. А пилят то, что за что реально платят деньги.
rshadow
> к сожалению
Ну как почему? Потому что остается целая не окученная ниша. Тут либо оракл брать в котором куча всего есть, но это априори не наш вариант. Либо лапу сосать, придумывая очередные костыли для постгри. Как все и делают. Печально… потому и «к сожалению».
А к деньгам тут весь диалог сводить не правильно. Как и в большинстве крупных открытых проектов там всего понамешено: начиная от энтузиазма,… через всякие фондейшены, донат и много чего еще… заканчивая зарплатой.
bormotov
Почему неправильно? Это же opensource, если в этой нише, вы видите деньги — наймите людей, пусть окучат. Вдруг найдутся энтузиасты, и так далее.
Я знаю сколько стоит Оракл, уверен, даже за деньги одной-двух лицензий энтерпрайз версии оракла некоторые вещи по облегчению развертывания и обслуживания кластеров PostgreSQL точно можно решить.
И конечно, там всё намешано, но как показывает жизнь, этой мешаниной должен кто-то управлять, а он хочет как минимум есть сам, и кормить семью.
sebres
[оффтоп] Какое там «хочеть есть сам» (умолчим про семью)… настоящий опенсорсник должен питаться флюктуациями мозга одними, сдобренными небольшой порцией радости довольных «клиентов»… Всегда в предвкушении сложной задачи… ну и т.д. и т.п.
Не в качестве претензии к комментаторам выше, просто лирическое отступление, так сказать от опенсорсника. [/оффтоп]
По теме же ветки: свои болячки есть и у таких монстров как ORA и (не побоюсь упомянуть всуе) у MSSQL, кто в теме, знает… И то что там из коробки преф-девочки-пряники-конфеты только чуть-чуть оправдывают их стоимость. А радости от того, что это все есть и даже саппорт худо бедно работает, к примеру та же поехавшая мастер-мастер репликация, с результатом «восстановите» вчерашний бакап transaction log-а, приносит тоже мало (от слова совсем).
При том, при всем, что я например себя гораздо комфортнее чувствую юзая PG или тот же мускуль (хотя работать приходится к сожалению больше с верхними двумя)… Как-то так.
bormotov
Простите, но я в разном opensource софте ковыряюсь уже лет 18 по необходимости. Иногда мне кажется, что лучше бы некотоыре «настоящие опенсорсники» из вашего определения, занимались чем-то другим. Например, пахали в каком-нибудь «кровавом энтерпрайзе», что бы исходных текстов результатов их деятельности не было видно, а в продуктовые результаты модно было тыкать палочкой с репликой «это же корпоративный говнософт, что бы вы от него хотите?»
Oracle это ад администрирования. Хоть за деньги, хоть за бесплатно — «привет из 80-ых».
MSSQL давно не касался, когда касался — всё было в лучших традициях Майкрософта — простые вещи сделать легко, сложные — или невозможно вообще, или не знаю какими усилиями.
У меня в PG, по-большему счету, никаких претензий нет, кроме того, что это в текущем виде, именно что база данных, а не продукт СУБД. Для 90-ых — это круто, для начала 2016 — нууу, ок.
А если вернуться к репликам про опенсорс — это хороший проект, по крайней мере из того факта, что внутрь заглядывать не возникало даже необходимости. То, что есть — работает ожидаемо. Того, чего нет — я всё равно понимаю, что мы за это платить не готовы.
И все мои возмущения по сути, сугубо на сравнении с более модными штуками типа mongo — с его веб-панелью, типа cassandra, которая всё сама, типа elasticsearch, который тоже практически всё сам, и так далее — приведите свои примеры.
sebres
Эх не хотел холиварить… а вот и не буду — только одно скажу — мы таки по разную баррикад, вы туда заглядываете, мы же им живём! посему вам вероятно меня не понять, а мне вас…
bormotov
Если вы живите только ради процесса — то точно не понять.
Если результат вашей «жизни» для вас важен, например в том виде, что пользователи «результата» получают радость использвания хорошего инструмента и решение своих задач с его помощью, то у вас есть шанс.
Представьте, что примерно так же «живу» теми задачами, которые я решаю. И мне от базы данных нужно, что бы «работала и не доставляла забот». Что бы если нужно добавить серверы в кластер, я это сделал за пол дня опытов на модели, а потом с заказчиком договорился о времени, и обновил рабочую систему и был уверен, что всё будет как нужно.
Если нужно порезать архивную таблицу по дате, что бы не писал руками триггеры, боясь ошибиться, а просто сказал «в этом поле дата, нужно нарезать на разделы по годам», мне сказали, сколько примерно времени эта операция займет, и я мог нажать условное «Поехали» в нужное время (когда нагрузка на базу меньше)
Попробуйте просто понять, что я решаю другие задачи, например как правильнее собрать эти самые данные, нужно ли их нормализовать и городить связку таблиц или пока можно просто тупо в одну свалить.
Почему есть несколько статей «как оптимизировать производительность PG», но нет ни одного инструмента в комплекте, который был посмотрел в базу и сказал «чувак, у тебя в системе 8G памяти, а под PG отдано 1G, давай добавим?» и сам бы прописал в конфиге? А через месяц опять «чувак, мы добавили до 6G, но реально больше 5G ни разу не потребовалось, можно уменьшить».
Или как-то иначе «чувак, у тебя в сутки дергается 100500 разных запросов, из них вот эти 5 работают очень медленно и неэффективно — всегда сканируют таблицу целиком, ты уверен, что так и нужно?»
Вы не заметили, что открытые исходники или закрытые — тут вообще не упоминается?
Вот по этим критериям удобства Oracle DB такое-же неудобное и неприятное. И если с PG вроде как в наших масштабах не нужен отдельный DBA, то с Oracle постоянно что-то вылезает, с кучей тонкостей и нюансов, и нужен человек с опытом, который хорошо понимает что вообще происходит и какие рукоятки из миллиона возможных крутить.
stalkerg
А если у вас там ещё веб сервер крутится? Этого не может и не должна знать БД. Вы ей приписываете совершенно не свойственные ей фичи. Этим всем и занимается админ вместе с DBA (или кто то один).
Так блин системы сложные! Ну нельзя в пару кликов мышкой собрать ракету для полёта на Марс.
bormotov
вы реально не понимаете о чем я, жаль.
У меня на календаре 2016 год, уже который год вовсю шагает докер, не говоря уже о том, что уже наверное с десяток лет, как шагают виртуальные машины.
И конечно я полностью с вами согласен, что БД не должна знать о том, крутится ли веб-сервер на этой же машине или нет. Но я не вижу никаких проблем, что бы в комплекте с БД была утилита, которая будет мониторить не только что там внутри БД, а еще и в окружении БД. И если какой-то collectd, вполне может собрать примитивные данные о количестве свободной и используемой памяти, CPU итд — то эта утилита тоже может.
И если есть на хосте свободные ресурсы, и эти ресурсы могут добавить производительности базе (да-да, статистика запросов, и вот это всё) — кто про это сможет узнать? Десяток человек по всему миру, который во всём этом хорошо разбирается? Ну ок, в паре сотен инсталяций с большой нагрузко люди счастливы от использования PG, остальные пробуют с «дефлотными настройками», 10% из них находит статью, что дефолтные настройки «тупо, что бы запустилось», и формулы как посчитать чуть по-лучше, и может быть что-то случайно покрутят. А оставшиеся 90% остаются, мягко говоря «не в восторге».
Пусть я даже ошибаюсь в порядке цифр, и грамотных людей тысячи, а счастливых заказчков сотни тысяч. Но ситуацию это не поменяет, сколько там скачиваний каждой версии?
Я где-то сказал о пера кликов и ракете на Марс?
stalkerg
Ещё раз: какое отношение эта утилита имеет к БД? Она реально больше к докеру имеет отношение чем к БД.
Если у БД надо узнать какие то параметры или статистику, то она всегда пожалуйста её дать может.
Опять же, если такая система (а не просто утилитка), так нужна то можете написать сами.
PG тут можно заменить на MySQL, Oracle, IBM DB2 и т.д.
по этому я не понимаю, у вас претензия к отрасли или конкретно к Postgres?
Вы написали про то, что слишком мало супер пупер специалистов во всех тонкостях БД. Я ответил в том ключе, что это неизбежно т.к. сложность текущих БД очень и очень высока.
bormotov
к БД — никакое, к продукту СУБД — полное.
Если для эффективного использования БД в моей задаче, в моём окруженнии, я вынужден изучать особенности БД, то простите, мне это надоело в 90-ых.
В 2000-ых я смотрю в строну альтернатив, которые меня не заставляют этим всем заморачиваться.
Если вы не прочли в комментариях выше — к PG у меня нет никаких претензий, которые я бы мог подкрепить деньгами на их устранение.
Но ни в одном новом проекте я не буду использовать PG (как и на Oracle, MySQL и всех прочих монстров 90-ых). Я не хочу становиться экспертом в БД, я хочу комфортно решать прикладную задачу.
Сложность использования текущих БД несоизмерима высока, в сравнении с задачами, в решении которых обычно берут их использовать. Наверное в этом отношении лучший баланс был у MySQL.
stalkerg
Простите конечно, но нету ни одной такой системы которая удовлетворила бы вас.
Если вы про это, то поверьте это не решает и 10% проблем таких систем. С той же Mongo под нагрузкой не меньше проблем чем с Postgres (на самом деле куда больше!!!). Или вон недавно сами монговци признались, что если хотите быстрый Mongo то используйте её поверх Postgres. :)
А честные транзакции? А уровни изоляции? Если вам это стало нужно, а у вас Mongo то у вас скорее всего проблема.
MongoDB и многие из этой волны, больше маркетинг чем реально что то ещё. Причём уже очень многие на этом обожглись.
В этом контексте это синонимы. Если вы думаете что под Системой Управлением БД понимается GUI и веб морда для настроек то вы ошибаетесь.
К слову на счёт веб морд: www.heroku.com/postgres такое вас устроит? :)
bormotov
оглянитесь вокруг — есть.
есть достаточно много систем с гораздо более пологой кривой «цена входа»
stalkerg
Цена входа в этих системах не так важна, как «цена выхода». Лучше сначала немного поучится чем, потом за голову хвататься, пытаясь перекроить архитектуру.
bormotov
это зависит от того, как устроен ваш бизнес. И зная риски «цены выхода», можно заранее строить бизнес так, что бы эти риски уменьшить.
А сразу вкладывать ресурсы в инструмент, который возможно потребуется заменять — это только если деньги некуда девать.
stalkerg
И всё же, ценна входа у Mongo сопоставима с Postgres. Когда начинаются кластеры или большие нагрузки, понятность, документированность и повторяемость явно за Postgres.
bormotov
не знаю как вы считаете цену входа, но вот пример из нашей практики: есть у нас небольшой по сложности логики сервис, которому нужно хранилище.
Когда его писали в прошлый раз, и хранилище сделали в таблицах, то получилось 8 таблиц. Не помню уже насколько там всё нормализовано, но вот так оно сейчас работает, много где.
Когда мы решили его переписать, то в монге это одна коллекция. Одна коллекция. Объем хранения небольшой — десятки тысяч записей. Есть у нас «аномально большой» клиент, где 300K документов в этой самой единственной коллекции в монге.
Это же еще небольшие нагрузки?
Идем дальше, мы в новой версии добавили еще одно хранение (старая версия сервиса работала как труба). Вот у этого аномального клиента там 4.7М записей, во второй коллекции.
В принципе, если сейчас подумать как бы добавлять в прошлую версию это жесамое, можно было бы в одну таблицу всё засунуть, аналогично. Хотя по хорошему, есть смысл нормализовать, и разложить на три таблицы минимум. Но в самой большой, было бы аналогично 4.7M записей.
То есть в нереляционной модели, уже меньше расходы на проектирование и реализацию.
Теперь мой либимое: монга у нас ставится инсталятором, вся от-и-до. Потому, что это тупо один mongod.exe, который даже сам виндовой службой регистрируется. Вкладывание одного исполняемого файла в пакет, заняло ну пару часов.
Я знаю, что можно и PG вложить внутрь и устанавливать автоматически, но сразу на винде начинаются всякие пляски с бубном — где-то ему не нравится русские буквы в «C:\Пользователи\», где-то оно не может получить админские права, где-то еще что-то, в зависимости от версии виндовса, и его русскости. Регулярно инженер при установке какие-то нюансы выгребает.
Что бы всё это побороть, думаю дня три нужно, не меньше, а скорее всего неделю. Поскольку у нас не тысячи установок, и «один раз поставил, работает долго», мы это всё не дожимаем до полной автоматики. Но очень хорошо понимаем, что если вдруг у нас будет рост количества установок, то для PG сразу нужно будет вложить время на разработку, плюс сразу заложить время на поддержку (у кого-то столкнулись, например, с грамотными админами, у них на сервере диска С нет как класса).
Для монги — заложено время на поддержку, но в разы меньше.
Когда начинаются кластеры, то всех «с монгой», я отправлю на их родной сервис, где за время триального периода можно собрать и запустить кластер, а потом снять его с мониторинга. До недавнего времени у сервиса был бесплатный вариант, с какими-то ограничениями по хостам, или группам. Если кто-то этим собирается заниматься регулярно — есть нормальный бесплатный обучающий курс, где рассказывают как собирать кластеры. С приличными лекциями и домашними заданиями.
Насколько я понимаю у той же Кассандры такое вообще из коробки в комплекте.
У того же ElasticSearch сборка кластера — максимум в конфиге написать имена хостов, если они сами друг друга бродкастами не найдут в одном сегменте сети.
stalkerg
Простите, но всё то, что я писал выше было серверное применение СУБД где 80% Unix. То, что вы пишете выше, это Embended использование. И тут MongoDB наверное не плохо смотрится на фоне SQLite или MySQLEmbended.
Ну и для справедливости, в 9.5 многие выше указанные ошибки в Postgres устранены.
Что вам мешает сделать таблицу с одним столбцом JSONB?
Я к стати начал понимаю где вы работаете…
На счёт кластеров: мне кажется их сравнивать как тёплое с мягким, у того, что вы привели в пример, нету ни ACID ни MVCС, не очень честное сравнение.
ЗЫ простите, что читаете весь этот диалог, но он всё же интересный. :)
bormotov
То есть небольшие приложения, масштаба 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 и прочих базвордов сильно была преувеличена.
Видимо, аналогичным маркетингом со стороны СУБД-монстров прошлых лет ;)
stalkerg
Если они не клиент/серверные и на Windows то Postgres думаю не для них.
Почему не можете? Можете! И даже индексы на это накинуть. :) Вы просто плохо знаете NoSQL возможности Postgres.
Везде где нельзя потерять данные, или где можно потерять консистентность.
Тут всё просто:
1. Если пользователь послал сообщение любовное подруге, а система сказала ОК, и тут сервер падает. Вот с Postgres после поднятия БД (если физически данные не похерились) это сообщение будет там лежать. В ваших системах мы можем его потерять. А если это денежный перевод? Короче если вам это не критично, для вас это не самые важные слова.
2. Несколько пользователей решили кинуть деньги на один счёт, если не делать блокировок, итоговая сумма может быть иной. т.е. если вам ненужны транзакции…
Насколько мне известно, не так много use cases где на выше указанные проблемы можно было бы закрыть глаза.
Я привёл в пример Heroku.
bormotov
конечно приложения клиент-серверные. Но небольшие, с точки зрения объемов данных, и развесистости структур данных.
Я вообще не знаю возможностей JSON в PG, потому, что когда мы начинали, никаких таких не было, и даже когда мы запустили в продакшн, тоже. Опять-же, JSON — это «всего лишь сопособ». У нас вообще всё по жизни XML (тяжелые наследия стандартов рожденных в кровавом энтерпрайзе), и когда мы смотрели, JSON вообще никак не участвовал в выборе. Но очень не хотелось документы каждый раз разбирать, при получении, и собирать перед тем, как отдать.
давайте на минуточку, вспомним, что все эти возможности потерять, они возникают при конкурентном доступе, а скорее всего, при высоко конкурентном доступе к данным.
Вокруг меня, 99% софта — «трехзвенная архитектура» — клиент напрямую с базой не общается. Более того, app-server, в 99% ходит в базу через ORM, и только в совсем тяжелых случаях, где-то есть какие-то curcor.execute(someSqlCode). Это значит, что у нас trade-of — заряжаем по полной в стандартную машинку задачу, (описание предметной области, нормализация, ORM), или заряжаем ту же задачу в другую машинку, модную-хипстерскую, где «документы», «коллекции», и так далее.
отлично, то есть RDBMS рулят и бибикают вокруг денег, и прочих сущностей строгого учета. Ниваропс. Какой процент таких задач?
хороший пример, но немного «не в тему».
Попробую более детально описать, как я делаю кластеры монги:
* на своих серверах устанавливаю агент монговского SaaaS
* даю этому агенту APIkey
* они все идут в SaaS
* там, через web-ui, сочиняю кластер, нужной мне конфигурации
* жду какое-то время, получаю готовый кластер
и если не нужно его автоматически обновлять и как-то комфортно мониторить, расширять и так далее — на этом использование SaaS можно завершить, продолжить использование кластера.
Если нужно — с недавнего времени это всё стало дорого, но я подозреваю, что за пол года год, появятся бесплатные замены. Потому, что собрать из монги кластер, это довольно простая работа, достаточно знать,
* какие демоны на каких хостах запускать
* в каком порядке
* какой конфиг им каждому загрузить в базу /admin
stalkerg
Я сейчас говорю в разрезе выходя 9.5, а не про 10 лет назад. Как я выше писал, сами монговци предлагают работать поверх Postgres. ;)
Это не отменяет вопроса надёжности и консистентности. Кроме того давайте не путать, напрямую юзер не стучится к БД, но у БД как были клиенты так и есть. :) Кроме того, в том же вебе иначе и не бывает, всегда есть некий программный сервер который обслуживает запросы пользователей и в свою очередь он стучится к БД. Но замечу ещё раз, это никак не влияет на то, что я сказал выше. ORM вообще параллельна всей нашей дискуссии.
Ещё раз, они рулят везде где вам будет дорого потерять данные, а это не меньше 90% случаев.
т.е. к примеру у юзера вылезла старая аватарка может и не страшно, а если вы потеряли его сообщение уже может быть очень плохо.
Мне всё же кажется, ваш пример крайне локальный и редкий, а вы пытаетесь его натянуть на все случаи работы с БД.
bormotov
надежность и консистентность можно «подкрепить» на уровне приложения, если известно, что у БД с этим не очень хорошо. Это всегда trade-of
Конечно у нас локальный и редкий, как и в подавляющем случае в RDBMS, их используют «потому, что умеют», а не потому, что это реально дает какие-то плюсы. Но это время закончилось с началом бума NoSQL.
stalkerg
Далеко не всё можно выправить. Вы ведь не будете реализовывать у себя в приложении WAL или Undo логи?
bormotov
WAL/Undo логи конечно не буду.
wiz
А я могу q:
bormotov
как давно у вас есть эта возможность?
Простите, у нас уже четыре года софт в промышленной эксплуатации.
stalkerg
Зря вы так думаете. Просто есть:
1. Не такой большой спрос на эти фичи.
2. Не все фичи легко реализовать исходя из текущей архитектуры. К примеру для UPSERT пришлось вводить новый тип блокировки (Postgres очень строгий MVCC).
bormotov
1. именно про небольшой спрос я сказал гораздо выше по треду.
2. судя по этому пункту про UPSERT, у нас разные понимания термина «продукт».
stalkerg
Я вас не понимаю. Фичу то давно хотели, и давно пытались только пока не получалось сделать. Сейчас вот всё срослось. Какие тут противоречия со словом продукт?
hippoage
Спрос на фичу репликации/кластеризации как раз большой. Ее делают множество около Postgres-контор. Им тоже на что-то жить надо, но от этого не менее печально.
stalkerg
Вот прям сейчас это пилится, уже есть хорошие результаты, надеюсь в 9.6 будет. Хотя главная там задача избавится от оверхеда и сделать работу с 10000 партициями без проседания производительности (сейчас в postgres уже на 100 есть траблы).
bormotov
по крайней мере вокруг меня разработка сдвигается в сторону от реляционных баз. Данные из реальной жизни становятся сложнее структурно, запихивание их в таблицы занимает всё больше труда. При этом альтернативные решения, всякие такие фишки уже дают.
У нас малюпусенькая «проблема» — есть таблицы, в которых архив данных, где ничего не удаляется. Нам бы хватило «нарезка по годам». На 100 разделах, говорите проблема? У самого старого клиента — 11 лет архив. На 30 разделах нет проблем?
Какие есть причины, не выпускать фичу, которая хорошо работает на малых объемах?
stalkerg
Именно по этому в Postgres есть JSON/JOSNB и в 9.5 появился json_set.
Не очень понимаю ваш вопрос. Тут отчасти как с UPSERT т.е. партицирования в Postgres нету, оно эмулируется через наследование таблиц. т.е. это достаточно сложный вопрос. Кроме того спрос (от крупных фирм готовых платить) есть именно на партицирование тысяч таблиц.
bormotov
мы всё таки на совершенно разных языках говорим, нет смысла продолжать.