После года разработки доступна (https://www.postgresql.org/about/news/1786/) новая стабильная ветка СУБД PostgreSQL 10. Обновления для новой ветки будут выходить (http://www.postgresql.org/support/versioning/) в течение пяти лет до октября 2022 года. Выбор номера версии 10 вместо 9.7.0 связано с переходом (http://www.databasesoup.com/2016/05/changing-postgresql-vers... проекта на новую нумерацию выпусков. Вместо трёхуровневневой нумерации (Major1.Major2.Minor) отныне будет применяться схема "Major.Minor", в которой "Major" указывает номер значительной ветки, а "Minor" - номер корректирующего обновления, не требующего перезаливки БД. Таким образом, первым корректирующим релизом PostgreSQL 10 станет 10.1, а следующей значительной версией PostgreSQL 11. Как и раньше значительные версии будут формироваться раз в год.Основные новшества (https://wiki.postgresql.org/wiki/New_in_postgres_10):
- Режим логической репликации (https://blog.2ndquadrant.com/logical-replication-postgresql-... позволяющий выборочно реплицировать только заданные таблицы или использовать репликацию в процессе обновления. Данный вид репликации манипулирует логическими изменениями на уровне выполняемых операций, в то время как традиционная репликация работает на очень низком уровне, перенося байтовые изменения в WAL-журнале;
- Добавлены встроенные возможности партицирования таблиц по диапазонам значений и спискам - разбивка теперь может задаваться (https://www.postgresql.org/docs/devel/static/ddl-partitionin... через выражения "PARTITION BY" и "PARTITION OF" в директиве "CREATE TABLE". Например:
CREATE TABLE padre (
id serial not null,
nombre text not null,
fch_creado timestamptz not null
)
PARTITION BY RANGE ( id );CREATE TABLE hijo_0
partition of padre (id, primary key (id), unique (nombre))
for values from (unbounded) to (9);CREATE TABLE hijo_1
partition of padre (id, primary key (id), unique (nombre))
for values from (10) to (unbounded);- Обеспечено распараллеливание с задействованием нескольких ядер CPU таких операций, как сканирование индексов и битовых карт, выполнение запросов со слиянием таблиц (JOIN);
- Возможность подтверждения коммитов на основе кворума для
предотвращения потери данных после выхода из строя сразу нескольких синхронно реплицируемых узлов. Например, теперь можно указать, что коммит должен быть подтверждён любыми К из N запасных синхронно реплицируемых серверов, без жестко заданной последовательности проверки;- Поддержка отслеживания (https://blog.2ndquadrant.com/traceable-commit-postgresql-10/) незавершённых коммитов - позволяет выяснить статус недавно запущенной транзакции для организации восстановления после краха или обрыва соединения;
- Поддержка аутентификации SCRAM-SHA-256 (https://ru.wikipedia.org/wiki/SCRAM) (вместо MD5) для организации более безопасного доступа по паролю;
- Многохостовый режим отказоустойчивости в libpq, при котором клиент соединяется с первым работающим хостом из заданного списка;
- Добавлен параметр "target_session_attrs", позволяющий клиенту запросить хост, доступный на запись или чтение;
- Для индексов типа Hash обеспечена поддержка репликации и повышена устойчивость к сбоям после крахов;- Добавлен новый тип полномочий, определяющий доступ к функциям мониторинга (pg_read_all_settings, pg_read_all_stats, pg_stat_scan_tables и pg_monitor);
- Добавлено выражение XMLTABLE (https://blog.2ndquadrant.com/xmltable-intro/), позволяющее представить XML-документ в табличном формате, что существенно упрощает разбор XML-данных, хранимых в БД;
- Поддержка полнотекстового поиска для типов JSON и JSONB;- Поддержка сжатия данных в журналах pg_receivewal (https://www.postgresql.org/docs/10/static/app-pgreceivewal.h...
- Добавлены средства для накопления статистики по корреляции данных в разных столбцах, которая может оказаться полезной для исключения выбора планировщиком некоторых ошибочных стратегий;
- Добавлена независимая от операционной системы реализация свойства локали "Collation", позволяющего задавать правила сортировки и методы сопоставления с учётом смысла символов. Реализация основана на libicu и идентична для Linux и Windows;- Увеличена производительность функции SUM(), преобразования кодировок символов, выполнение выражений, группировки множеств и выполнения операций JOIN над уникальными столбцами. При выполнении аналитических запросов над большим числом строк наблюдается ускорение до 40%;
- Из нарушающих совместимость изменений отмечается переименование "xlog" в "wal", прекращение поддержки устаревшего протокола FE/BE 1.0, изменение настроек по умолчанию для репликации и резервирования (pg_basebackup), прекращение поддержки значений времени (Timestamps) с плавающей запятой, удаление contrib/tsearch2 и прекращение поддержки в pg_dump баз данных от PostgreSQL 7.4 и более ранних выпусков.
URL: https://www.postgresql.org/about/news/1786/
Новость: http://www.opennet.me/opennews/art.shtml?num=47337
Вот и до этих мода на симуляцию развития рисованием красивых цифр дошла (
Ребята дело делают. Пофиг на циферки.
Наоборот, сменили нумерацию на более логичную. Бинарная несовместимость данных между версиями X.Y и X.Y+1 выглядит странно.
Ага, а потом опять дойдут до версий 50 и решат что слишком много и вернуться обратно.
Не они первые, не они последние.
less и systemd возвращаться не собираются
Правильно, вот и пусть systemd идёт как можно дальше в less :)
Эй, вот не надо хотя бы в less свой системде пихать! А то чем файлы-то смотреть? Придётся ж more из фряхи портировать.
С таким циклом разработки Postgre SQL 50 выйдет в 2057 году...
Дожить бы до этого.....
офиц. пресс-релиз на русском https://www.postgresql.org/about/press/presskit10/ru/
Хорошая субд для тех кому скорость не нужна
> Хорошая субд для тех кому скорость не нужна"Сильное заявление, проверять его я, конечно, не буду" (c)
Говорить о скорости можно только в контексте определенных юзкейсов и совместно с иными требованиями, такими как гарантия целостности. Так-то записать данные в /dev/null быстрее всего.
Is /dev/null webscale?
> Is /dev/null webscale?No, it's super-trans-hyper-pooper-webscale[I]!
> No, it's super-trans-hyper-pooper-webscale!Pooper это профессия от слова poop?
>> No, it's super-trans-hyper-pooper-webscale!
> Pooper это профессия от слова poop?Словарь не тут. ---Ж*** есть, а слова нету.
> Хорошая субд для тех кому скорость не нужнаНаучись свой код оптимизировать.
>> Хорошая субд для тех кому скорость не нужна
> Научись свой код оптимизировать.Ну соптимизируй мне join чтобы из 20 таблиц собирал аналог Mongo-вского документа хотя бы в 10 раз медленнее? А то пока что все 50 получается.
Про JSONB/JSON не надо, функционала по сравнению с полноценной документной субд с гулькин гуль и при этом тормознее.
Итого, "Хорошая субд для тех кому скорость не нужна"
Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но зато уже хоть удобно что-то делать на ней.p.s. Да, я знаю usecase-ы где Слон быстрее Монги. Полнотекстовый поиск и "вытащить только пару полей из большого документа". Но жабовский полнотекстовый поиск ещё быстрее и продвинутее оказался, по второй проблеме - пока терпим. Как обойти тоже понятно. В остальном сплошнейшие плюсы.
Соптимизируй обновление этих 20 таблиц в монго, чтобы было устойчиво к сбоям и не оставляло БД в противоречивом состоянии, если что пошло не так. И чтобы это было хотябы в 10 раз медленее нормальной субд.
>Соптимизируй обновление этих 20 таблиц в монго,Батя, не выставляй себя на посмешище, в Монго это будет одна таблица. Почитай про mongo data model, прежде чем комментировать.
Какие проблемы с противоречивостью тебе померещились? В Монге все операции над документом атомарны, в том числе всякие прикольные навроде fineOneAndDelete или update с включенным upsert. А в РСУБД надо лепить транзакции и опять ТОРМОZZZzzzzzzzZZZZZа. Хотя, вы привыкшие, не замечаете :))))))
Имеется ввиду непротиворечивое обновление 20 документов.
Для одаренных: В МОНГЕ ЭТО ОДИН ДОКУМЕНТ.
> Для одаренных: В МОНГЕ ЭТО ОДИН ДОКУМЕНТ.У тебя вся БД — один документ? Ну рад за тебя.
Ни разу не пользовался монгой и решил посмотреть что же у них за data model такая волшебная.
https://docs.mongodb.com/manual/core/data-model-design/
И тут оказывается, что их 2-е: Embedded Data Models и Normalized Data Models.
Если под Ваши задачи Вам хватает Embedded Data Models и нужна скорость, то монго Ваш выбор.
Но то что Вы даже не понимаете, что полно задач где нужна нормализация говорит только кто выставил себя на посмешище и ставит под сомнение остальные Ваши утверждения.
>Вы даже не понимаете, что полно задач где нужна нормализацияНе только эксперт по СУБД, сегодня впервые почитавший про mongo, ещё и Телепат? Я вот прекрасно понимаю где Монга не нужна и использую там другие решения. В отличие от местных фанатиков, которые лепят ВСЁ на РСУБД. При этом получая тормоза и MVCCшные глюки. Почитай как всё клёво с Слоне с репликацией и надежностью хранения:
В отличие от местных фанатиков, которые лепят ВСЁ
> на РСУБД. При этом получая тормоза и MVCCшные глюки.Фанатиком не являюсь, но считаю что для общих случаев, лучше подходит полноценная РСУБД.
А применять все NoSQL надо там где нужно и не больше.
Про надежность, ошибки бывают у всех. И то что есть их исправление в логах это хорошо. А то что в ченджлоге такого нет, не говорит о отсутствии ошибок.
И да у нас все на Оракле все еще, но в свете импортозамещения по постгре посматриваем, пока издали.
> Почитай как всё клёво с Слоне с репликацией и надежностью хранения:
> https://habrahabr.ru/company/southbridge/blog/322624/почитал. Действительно интересно. Но прямо в этой версии добавили логическую репликацию. Может и по мотивам этой статьи. Так что дело движется. Хотя насколько я понимаю ни у Постгри, ни у Марии нормальной репликации нет. Есть разные поделки поверх. Каждая из которых под свою задачу. Что ж репликация бывает разной и возможно и правда нужны разные реализации, хотя лучше если они в официальной версии, а не поделка сверху. Тем не менее это не говорит, о том что везде надо применять NoSQL и в частности Монгу. То что в какой-то СУБД в каких-то версиях была ошибка приводящая к возможному повреждению данных при репликациях, не говорит о надежности NoSQL.
> Тем не менее это не говорит, о том что везде надо применять NoSQL и в частности Монгу.Фраза была "ПГ хорошая, но тормозная СУБД". Кстати, с Оракле у меня опыта даже поболее, чем со Слоном. Производительность можно ещё в 1.5-2 раза делить :) а уж костыльность и замшелось просто бесконечны.
Я бы лично хотел оказаться в будущем, где NOSQLей победят объектные СУБД. ObjectDB по описанию тортище. Но небесплатный...
> То что в какой-то СУБД в каких-то версиях была ошибка приводящая к возможному повреждению данных при репликациях, не говорит о надежности NoSQL.
Надежда умирает последней.
На всю ту воду, что ты тут льешь, могу только посоветовать выровнять руки. Топором.
> Надежда умирает последней.Хорошо, что ты не Надежда.
Используйте под задачи профильные средства их решения. Автомобили тоже хуже самолётов летают.
Nikolay Shestakov:
Подход обозначенный Вами либо вытекает из вашего непрофессионализма, либо является простым троллингом. Так или иначе, расскажу свое мнение.
1. Несколько лет назад участвовал в разработке проекта со сложной логикой на стороне сервера приложения. База данных использовалась в качестве простого реляционного хранилища и взаимодействие с ней было реализовано через ORM Hibernate. Поддерживаемыми СУБД были MS SQL, Oracle и Postgres. Мы проводили нагрузочное тестирование на базе размером около 500Gb на не топовых серверах (памяти было толи 32Gb, то ли 64Gb. Точно не больше). Сервер приложений и СУБД находились на разных серверах. Нагрузка подавалась эмитацией работы реального пользователя через силениум (были несколько базовых сценариев работы пользователи и мы их полностью воспроизводили). Так вот: самой быстрой базой при нашем профиле использования оказалась MS SQL, а Oracle и Postgres были примерно одинаковыми (разрыв не превышал 10% от самой "быстрой" и самой "медленной" БД).2. На текущем месте работы мы пытались использовать MongoDB в нескольких проектах.
В одном из них размер базы около 250Gb (около 150M записей в одной таблице). База шардирована и реплицирована.
При эксплуатации MongoDB такого объема возникла проблема с добавлением новых нод: на ребалансеровку шардов стало уходить до нескольких недель. В итоге конкретно в этом проекте от использования MongoDB отказались.
При этом MongoDB продолжает использоваться в проектах где объем базы гораздо меньше.3. Так получилось, что нам приходится для анализа хранить логи за последние 3 года (а в некоторых проектах и дольше). Ежедневный размер логов только сервиса в разработке которого принимаю участие я около 30Gb. Итого за три года 3*365*30Gb ~ 32Tb. При этом по этим логам периодически считается всякая статистика.
Ни postgresql ни MongoDB для этой задачи не подходят. Для хранения логов мы используем хранилище с возможностью выполнения Map/Reduce .
Как можно догадаться,
* в первом примере хорошо себя показывает Postgres, и совершенно не пригодны ни MongoDB, ни Map/Reduce;
* во втором примере есть как удачный опыт использования MongoDB, так и неудачный;
* в третьем не подходит ни MongoDB, ни Postgres.Так, что не надо говорить, что одна база лучше другой, а надо говорить, что в конкретно этой задаче база такая-то показала себя лучше чем база такая-то.
1. В первом случае Монгу не тестили, хотя костыль под названием ORM это как раз попытки сделать из РСУБД Монгу (только очень тормозную). А можно просто взять быстрый Монго.2. Про шарды ничего не скажу, хватает одного сервера с 1.3ТБ данных, ничего не тормозит. А репликация очень быстрая, за день с нуля синхронизируется на обычном эзернете.
Случай три: map/reduce в Монго как раз есть.
Итого, либо ДРЕВНЯЯ писулька про Монгу 2.х, либо ламер писал.
В целом наблюдение: все рсудб уже давно в периоде стагнации, ничего путнего не добавляется, либо добавляется криво. Как например графы и json к слону, скорость как у черепахи Тортиллы.
А носкли и в частности Монго развиваются семимильными шагами. Плюс, из-за более узкой специализации разрывают универсальные решения в виде рсубд.
Да, в первом случае MongoDB не тестили ибо тогда (2008 год) про такую СУБД еще никто не слышал.
Не отрицаю, что я ламер в документо-ориентированных СУБД, это точно подмечено.
Но зато у меня есть достаточно большой опыт в реляционных СУБД и некоторый опыт в Map/Reduce (и да, не на MongoDB).А вот на ORM Hibernate наезд был абсолютно зря:
1) Для документо-ориентированных СУБД тоже существуют свои ORM, например, OMG от тогоже Hibernate, а это значит, что с документо-ориентированными СУБД тоже есть класс задач, где проще отдать часть операции прослойке, а не делать самому.
2) Hibernate занимается вполне понятной задачей: отображает результат выполнения SQL запроса на объекты (и да, немного упрощает обновление данных и кеширование)
3) Избавляет от необходимости самому учитывать мелкие особенности каждой из поддерживаемой СУБД.И из последнего Вашего предложения вытекает, что узкоспециализированное решение MongoDB, хорошо подходит к задачам которые Вы решаете. А все ваши наблюдения про РСУБД - это ваши наблюдения в проекции решения ваших задач. В рамках задач решаемых мной, развитие РСУБД, в частности, postgres продолжается, и продолжается весьмы активно.
> И из последнего Вашего предложения вытекает, что узкоспециализированное решение MongoDB,
> хорошо подходит к задачам которые Вы решаете....которые я решаю на Монго. А есть задачи которые я решаю НЕ на монго. И вообще, если уж связываться с РСУБД, то я всеми руками за ORM (можно было не распинаться).
Изначальный тезис был: "Постгрес (и другие рсубд) тормоз". Его люто минусуют, но сказать в ответ нечего 8))))
1) Вот твои слова "Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но зато уже хоть удобно что-то делать на ней."Из этой фразы вытекает, что пользоваться РСУБД без ORM неудобно.
2) РСУБД медленны при решении твоих задач, и надо тогда так и говорить, что в такой-то задаче РСУБД медленнее MongoDB, а не голословно утверждать, что РСУБД всегда медленнее MongoDB.
>пользоваться РСУБД без ORM неудобноСовременному программисту с ООП головного мозга - безусловно. 8) Некоторые ретрограды не признают ООП, не признают ОРМ, сидят себе пишут SQL-запросы от звонка до звонка. Скорость разработки ниже плинтуса.
Современному погромисту с жабой головного мозга лучше вообще молчать. Молчать и слушать, что говорят.
> Скорость разработки ниже плинтуса.А скорость работы конечного продукта?
Ты из клованов орущих "ооп тормозит111". От правильного ооп прога только быстрее 8)))
Дело не в ООП, хотя оно тоже накладывает штрафы в районе 10% на скорость и объем, а в ORM, который очень плохо ложится на SQL и либо заставляет тратить еще больше времени на оптимизацию по сравнению с написанием чистого SQL, либо спокойно может дать замедление на порядки в отдельных случаях.
> Дело не в ООП, хотя оно тоже накладывает штрафы в районе 10%Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг
Про орм - оно может и выигрыш давать, от рук зависит. Но монга как раз рулит там всё без сюрпризов - быстрее и орм и голого скуля в разы. Поэтому сейчас 50% проектов на носклях, 40% орм. 10% хипсторский скуль 8))
> Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, ггггТо есть ты пытаешься мне доказать, что ООП дает штраф не в 10%, а все 1000%. Ну окей, верю, что в жабке это так, но я говорил про ООП в нормальных языках.
> Про орм - оно может и выигрыш давать, от рук зависит.
Само собой, если кривизна рук погромиста не позволяет ему писать нормальные SQL запросы, то ORM может иногда эту кривизну компенсировать.
>> Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг
> То есть ты пытаешься мне доказать, что ООП дает штраф не в
> 10%, а все 1000%. Ну окей, верю, что в жабке это
> так, но я говорил про ООП в нормальных языках.Это не отменяет того факта, что жабка номер один везде, кроме опеннета. 8))
>> Про орм - оно может и выигрыш давать, от рук зависит.
> Само собой, если кривизна рук погромиста не позволяет ему писать нормальные SQL
> запросы, то ORM может иногда эту кривизну компенсировать.Совершенно неправильно, ORM кривизну не компенсирует. Максимальный профит от ORM когда прогер знает SQL и ORM, но его избавляют от рутины.
> ORM, очень плохо ложится на SQLТы из престарелых ДБА? Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку. Соответственно, с самописным ДАО ничего не меняется, надо так же д вприсядку. А уж рефакторинг превращается в лютый гемор, в отличие от ОРМ.
В итоге, правильный подход: девелопим продукт с ОРМ, потом если развитие ОСТАНОВЛЕНО (что почти никогда не бывает), можно выкинуть ОРМ. Но в прямых руках это не даст и нескольких процентов выигрыша. Соответственно, почти никто не делает.
> Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку.Я тебе сейчас очень страшную вещь скажу, только ты присядь. ООП тоже очень плохо ложится на реальность. Листок бумаги с буковками не имеет методов, он не умеет сам ничего делать. И скрепленные или подшитые такие листочки, образующие документ, тоже не умеют сами по себе ничего делать, даже добавить новые листочки. Аналогично с папкой, в которой лежат документы и шкафом, где хранятся эти папки. Все они не умеют делать ровным счетом ничего. Это данные, но без методов. Вот такая вот суровая реальность. А вот схема работы реляционных БД, в которой есть СУБД(библиотекарь, секретарь) и собственно БД(шкафы, полки, папки, каталоги для индексации) почему-то очень реальность напоминает. Может потому, что с нее писалась.
>> Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку.
> Я тебе сейчас очень страшную вещь скажу Листок бумаги с буковками не имеет
> методов, он не умеет сам ничего делать.Ну и глупость пишешь. Ты из тех "спецов" по ООП у которых прям настоящее наследование на struct-ах делается.
У нас шардинг кластер монги на 1.3Тб. Действительно, если канал между серверами слабый, то синкнуть реплеку простым добавленим сервера очень долго, так что оплог может закончится. Лучшим способом является залочить одну из реплек на запись и тупо скопировать файлы rsync-м с сжатием при копировании. Но это всё максимум сутки, несколько недель это какая-то фантастическая цифра. Никакого оплога на такое не хватит, звучит как то что вы придумали эту цифру.
Положи свой документ в колонку BSON и живи спокойно.
>Положи свой документ в колонку BSON и живи спокойно.Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги на 1меговых объектах.
На маленьких не тестил, но полагаю, что ничего похожего на 100к/сек не будет.Про неудобство работы молчу. Местами монговский контейнер BSON даже удобнее родных объектов. Слон НИЧЕГО подобного не предлагает.
>>Положи свой документ в колонку BSON и живи спокойно.
> Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги
> на 1меговых объектах.
> На маленьких не тестил, но полагаю, что ничего похожего на 100к/сек не
> будет.
> Про неудобство работы молчу. Местами монговский контейнер BSON даже удобнее родных объектов.
> Слон НИЧЕГО подобного не предлагает.Просто неасилятор и профан в postgres, а так же фигляр и позёр по жизни. Вот и весь разговор.
>[оверквотинг удален]
> 50 получается.
> Про JSONB/JSON не надо, функционала по сравнению с полноценной документной субд с
> гулькин гуль и при этом тормознее.
> Итого, "Хорошая субд для тех кому скорость не нужна"
> Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но
> зато уже хоть удобно что-то делать на ней.
> p.s. Да, я знаю usecase-ы где Слон быстрее Монги. Полнотекстовый поиск и
> "вытащить только пару полей из большого документа". Но жабовский полнотекстовый поиск
> ещё быстрее и продвинутее оказался, по второй проблеме - пока терпим.
> Как обойти тоже понятно. В остальном сплошнейшие плюсы.Чего-чего ?! :-D они там в монге своей добавили хотя бы валидацию json при добавлении документов ? или до сих пор вставляй что угодно, а потом map/reduce валится (ни о каких зачатках ACID речи ясное дело не идет)
> Чего-чего ?! :-D они там в монге своей добавили хотя бы валидацию
> json при добавлении документов ? или до сих пор вставляй что
> угодно, а потом map/reduce валится (ни о каких зачатках ACID речи
> ясное дело не идет)давай сюда пример инвалидного json, который съест монга 3.4 или 3.2, а то сам знаешь кто.
"Жабист" в нике объясняет такое мнение. :-)Если рассматривать СУБД чисто как слой персистенции, и вся работа с оной сводится к fooRepository.find(id) и fooRepository.store(entity) - тогда, конечно, РСУБД не только не нужна, но и мешает из-за impedance mismatch. Тут, конечно, любое документное хранилище подойдет лучше.
Но это вообще не та задача, для которой РСУБД задумывались.
> ...Mongo-вского документаХоспыдя... хипстеры, откуда вы лезете-то?? *фэйспалм* Из подвёрнутых штанов? Сидите уже в своём болоте и не гоните волну! Вот хорошо, что NoSQL появился - как только завёл про него речь - всё, увози д*#била!
Хорошая БД для тех, кому нужна надежность. Ну а для сайтиков есть все остальное, пользуйтесь.
> Хорошая БД для тех, кому нужна надежность. Ну а для сайтиков есть
> все остальное, пользуйтесь.И, вместе с тем, это — БД, которой никогда не было удобно пользоваться.
>Хорошая БД для тех, кому нужна надежность.Ну-ну. На моей памяти совсем недавно проскакивали багфиксы в духе "ой, мы при некоторых обстоятельствах теряли данные, ну вы эта, обновитесь". Причём не раз.
Это ты так бесишься потому что все с java на go переходят, а в go ты ничего не смыслишь и никому не нужен, да?
На go? Люто проиграл с этого. Казалось, что на go переходят только php и python программисты. А теперь я узнал, что и джависты, которые не смогли осилить скалу.
А MongoDB вообще не работала.> new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4
> А MongoDB вообще не работала.
>> new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4Ты правда такой или прикидываешься? Джепсены тестят момент переключения мастер-слейв. Подавляющее большинство субд его ФЭЙЛЯТ. И монга УЖЕ не фэйлит, а ваш слон стыдливо не заказывает тест. В пг вообще есть репликация-то? Судя по комментам какие-то внешние костыли. Так что не позорься уж
А сам ты правда такой или прикидываешься? MongoDB фейлила, причём не раз и продолжит фейлить, потому что ошибки есть во всех программах.
LOL
> Хорошая субд для тех кому скорость не нужна
>> жабист
Зависит от объема данных. Или вам больше по душе снежный ком MySQL?
> Зависит от объема данных. Или вам больше по душе снежный ком MySQL?Нет, не зависит.
Full table scan, 30 млрд. записей, 600-800 мсек. Нужно только думать головой.
Если запись длиной хотя бы в 70 байт, то это три терабайта в секунду, что на четыре порядка превосходит максимальную скорость чтения ssd. То есть только для того, чтобы сделать проход по данным, нужно параллельное чтение с 10k ssd. Ну давай расскажи, как это преодолевается теми, кто думает головой.
Может он на ram disk какой выгружает это барахло предварительно? Но durability будет шикарная, да.
3 ТБ/с даже для оперативки овердохрена, не говоря уж о том, что прочитанные данные надо ещё как-то обработать.
> 3 ТБ/с даже для оперативки овердохрена, не говоря уж о том, что
> прочитанные данные надо ещё как-то обработать.Шардинг же... таблица раскидана на 100 серверов...
>> 3 ТБ/с даже для оперативки овердохрена, не говоря уж о том, чтоОб этом и речь - головой нужно думать, если у тебя есть нормальный инструмент.
> Шардинг же... таблица раскидана на 100 серверов...index-only scan по одному измерению + partitioning по другому. Посмотрел на результаты - шардинг оказался даже не нужен.
Близко. Оракл же.
"Скорость" ты сравнивал по select count(*), полагаю?И не учитывал спец. сборки вроде Postgres XL, Netezza или GreenPlum.
> "Скорость" ты сравнивал по select count(*), полагаю?Это известный эксперт по замерам.
Его линейка длинее!!!
У него даже grep тормозит. grep -F 'Карл!'
> И не учитывал спец. сборки вроде Postgres XL, Netezza или GreenPlum.
Ах! Оставьте.
>> "Скорость" ты сравнивал по select count(*), полагаю?
> Это известный эксперт по замерам.
> Его линейка длинее!!!
> У него даже grep тормозит. grep -F 'Карл!'Чорд! У него опять обострилось сравнения тёплого с мягким по дюймовой линейке, в #68 выше:
"Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги на 1меговых объектах."
#разувидеть ..."на моих задачах" читать "на моём радиусе кривизны"
> Ах! Оставьте.
XL или XC? А то Коичи там кучу проектов нафоркал, который настоящий - без поллитры не разберёшь.
> XL или XC? А то Коичи там кучу проектов нафоркал, который настоящий
> - без поллитры не разберёшь.Форка на форке, а в итоге толку ноль все сами себе буратины.
> "Скорость" ты сравнивал по select count(*), полагаю?
> И не учитывал спец. сборки вроде Postgres XL, Netezza или GreenPlum.Моя основная рабочая база 1.3ТБ всего, монга прекрасно тянет и на одном сервере, зачем мне ваши Postgres XL, ещё и не бесплатные наверно? Объекты примерно в 1мегабайт.
Из другого проекта - объекты маленькие до килобайта, итого гигов 100 всего. Но по структуре штук 20 разных типов с разными полями. У монги скорость загрузки 100к в сек, отдача 1-2мс.
Из третьего проекта - объекты в районе 1кб, поля все одинаковые (но иерархические само собой) . Надо было отсекать дубли, создал unique index, монга после 200млн записей стала тормозить на вставку до 200зап/сек. Сервер с 16ГБ ОЗУ, больше нет. Думаю, ну всё, Монга, прощай. Начал переносить в Слона, а он сдулся намного раньше. А уж mass update одного поля в базе 200млн записей это просто смерть всему и вся. Привет ACID. В Монге вообще не влияет на скорость работы.
В целом, ACID нужен "почти никогда", а тормозит он "мама не горюй". Щас понабегут банкиры, у всех транзакции в слоне и миллиарды ворочаются.
Не корректно сравнивать SQL и noSQL СУБД.
Всё таки всё зависит от контекста использования. Можно микроскопом гвозди забивать, а можно и ломом коктейли мешать.
> можно и ломом коктейли мешатьРтутные коктейли урановым ломом?
>> можно и ломом коктейли мешать
> Ртутные коктейли урановым ломом?Железные же, всплывают!
Мне вот просто интересно, откуда у вас такие базы по терабайту? Что вы в них храните, результаты экспериментов на БАКе?
У GitLab размер базы около 310 гигов был на момент сбоя в январе. По GitHub информацию не нашел, но данные GitHubArchive за 2016 год весят 766 гигов ( https://bigquery.cloud.google.com/table/githubarchive:year.2... ).
> Мне вот просто интересно, откуда у вас такие базы по терабайту? Что
> вы в них храните, результаты экспериментов на БАКе?Уровень экспертов опеннета налицо? 20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы. А БАКом генерят сотни терабайт в год.
Не вижу смысла расписывать, что в этих 1.3ТБ.
>> Мне вот просто интересно, откуда у вас такие базы по терабайту? Что
>> вы в них храните, результаты экспериментов на БАКе?
> Уровень экспертов опеннета налицо? 20-50ТБ это объём ERP-базки не самой большой по
> меркам планеты конторы. А БАКом генерят сотни терабайт в год.'2007: "15 PetaBytes of new data each year stored"
http://www-conf.slac.stanford.edu/xldb07/xldb_lhc.pdf
<= https://duckduckgo.com/?q=LHC+CERN+database&t=ffab&ia=web"Since 2001 - RDBMS + files
Idea of consistent storage of all data in databases was dropped
Hybrid model
• Bulk data in files (largely read-only)
• Only key meta-data in RDBMS""110 server nodes - RHEL 5, Oracle 10g"
"Tomorrow
- Petabyte flash-RAM and in-memory databases?"+ '2008 http://www-conf.slac.stanford.edu/xldb08/slides/xldb2_cern_g...
+ '2009 http://openlab.cern/sites/openlab.web.cern.ch/files/presenta...
'2012 https://duckduckgo.com/?q=LHC+CERN+mongo
? В 2012-ом какую-то "мелочь" в mongo сложили.http://www.techrepublic.com/blog/european-technology/cern-wh.../ :
..."will generate some 22PB of data this year, and that's after throwing away 99 per cent of what is recorded by the LHC detectors."
'2017: http://www.techrepublic.com/article/cern-we-generate-1pb-eac.../"Cern: 'We generate 1PB each second."
"While the bulk of this data is thrown away"... //сколько пишут не сказали, вроде.> Не вижу смысла расписывать, что в этих 1.3ТБ.
>Уровень экспертов опеннета налицо?
>20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы.Вы бы не могли назвать эту контору? а так же каким образом были получены вами сведения о размере упомянутой базы?
>Не вижу смысла расписывать, что в этих 1.3ТБ.
В зависимости от ответа выше - будет комментарий и сюда.
>>20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы.
> Вы бы не могли назвать эту контору? а так же каким образом
> были получены вами сведения о размере упомянутой базы?Мусохранск-нефтегаз. Знаю, сколько стораджа сапёрам дали. Уже больше 20, хотя да, наверняка там 19.5тб архив порнухи занимает, а сама база 500. Ведь не бывает баз больше пресвятого гитхаба. Ггг
>>>20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы.
>> Вы бы не могли назвать эту контору? а так же каким образом
>> были получены вами сведения о размере упомянутой базы?
> Мусохранск-нефтегаз. Знаю, сколько стораджа сапёрам дали. Уже больше 20, хотя да, наверняка
> там 19.5тб архив порнухи занимает, а сама база 500. Ведь не
> бывает баз больше пресвятого гитхаба. ГггИ откуда такая уверенность что на этом сторадже лежит именно ERP база?
Надо понимать, что если в базе хранится что-нибудь специфическое, то что именно - это NDA (информация для служебного пользования)Про БАК и как они хранят данный можно послушать где-то здесь https://events.yandex.ru/events/ds/17-sept-2016/
(Очень кратко: 99,9% данных сразу удаляется и не хранится)
А если общими словами, то что такое 1TB:
1) 700 полнометражных фильмов (в низком качестве)
2) 500K музыкальных произведений (в низком качестве)
3) Логи за 1 месяц среднего (или даже небольшого) сервиса
Ну и много еще чего
> А если общими словами, то что такое 1TB:
> 1) 700 полнометражных
> 2) 500K музыкальных
> 3) Логи за 1 месяц среднего15 PetaBytes =>
"CD stack with 1 year LHC data! (~ 20 Km)"
--стр.14 http://openlab.cern/sites/openlab.web.cern.ch/files/presenta...+++"А во флоппы-дисках я значииительно длинееее."
>Хорошая субд для тех кому скорость не нужнаСтарый (очень) анекдот на эту тему.
Спорят 2 программиста:
- Уменя программа работает быстрее твоей в 10 раз
- Зато моя работает правильно, а твоя нет
>Зато моя работает правильно, а твоя нетСамый смех в том, что Pg не только медленнее, ещё и работает неправильно. Я что-то в changelog Монги не помню ничего про потерю данных. А в Pg было и не раз.
Кстати, как там в правильном Pg с репликацией, полноценный master-slave есть, само переключает? Ни одна acknowledged запись гарантированно не теряется? Или может master-master уже из коробки появился?
Интересное чтиво:https://habrahabr.ru/company/southbridge/blog/322624/
Из эпичного:
логически небольшое обновление (скажем, запись нескольких байт) становится гораздо более серьезной и ресурсоемкой операцией на физическом уровне.
После того как мы обновили год рождения al-Khwārizmī, не изменились ни первичный ключ записи, ни значения имени и фамилии. И все же индексы приходится обновлять, поскольку в базе данных появился новый кортеж. Для таблиц с большим количеством вторичных индексов эти дополнительные шаги могут приводить к значительным накладным расходам на запись. Например, для таблицы с десятком индексов обновление поля, покрытого лишь одним индексом, должно быть распространено на остальные девять, поскольку необходимо прописать в них ctid новой строки.Проблема с усилением записи затрагивает и репликацию, которая выполняется на уровне представления данных на диске. Вместо передачи небольшой логической записи, такой как, например, «Изменить год рождения для ctid D, установив его в 770», СУБД должна переслать все элементы WAL, касающиеся четырех вышеупомянутых операций, сопровождающих запись. Таким образом, проблема усиления записи переходит в проблему усиления репликации, и поток репликационных данных Postgres очень быстро становится настолько значительным, что может занять большую часть доступной пропускной способности сети.
Во время стандартной операции по увеличению емкости базы данных, при которой использовался механизм повышения роли реплики, мы столкнулись с ошибкой в Postgres 9.2. Реплики некорректно обрабатывали переключение шкалы времени (timeline switch), в результате чего некоторые из них неверно применяли обновления WAL. Из-за этой ошибки некоторые записи, которые должны были быть деактивированы механизмом версионирования, не получили соответствующую пометку, то есть остались активны. поскольку ошибка проявлялась на всех серверах, каждый из них портил разные строки, то есть на одной реплике строка X могла быть повреждена, а Y нетронута, но на другой реплике строка X могла быть в порядке, а Y — повреждена. На самом деле мы точно не знали, на скольких репликах были поврежденные данные, а также проявлялась ли эта проблема на мастере.
Переключалка через pacemaker отлично работает.
А без Shared Storage? А то так можно сказать что репликацию поддерживает и SQLite.
https://www.youtube.com/watch?v=SNzOZKvFZ68
https://jira.mongodb.org/browse/SERVER-2237?jql=issuetype�...
> https://jira.mongodb.org/browse/SERVER-2237?jql=issuetype�...Huge data loss after altering files in dbpath on a running instance
Это баг в мозге у одмина, зарепортившего такое. Давай уже не багтрекер, а реальный changelog с data loss.
Ещё половина багов в репликации, что уже привели в идеал в 3.4, а в Слоне до сих пор ОТСУТСТВУЕТ вообще.
https://aphyr.com/posts/322-jepsen-mongodb-stale-reads
In this Jepsen analysis, we develop new tests which show the MongoDB v0 replication protocol is intrinsically unsafe, allowing the loss of majority-committed documents. In addition, we show that the new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4. While the v0 protocol remains broken, patches for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite. This work was funded by MongoDB, and conducted in accordance with the Jepsen ethics policy.
Да, с версии v3.4 наконец перестали самопроизвольно реплики вылетать в unrecoverable. До того, 2-3 раза в месяц приходилось перезаливать реплику из соседней.
Расскажи нам опять, что монга круче справиться ;)
Презентация к релизу https://postgrespro.ru/media/2017/10/05/postgres-10-hse-2017...
На сайте пока не даёт выбрать 10 для загрузки.
Для Centos 7 можно установить так:
1. Устанавливаем PostgreSQL 10.X Yum Repository Configuration
rpm -i https://download.postgresql.org/pub/repos/yum/10/redhat/rhel...
2. Устанавливаем сервер через yum:
yum install postgresql10-contrib.x86_64 postgresql10-server.x86_64
ClickHouse, RocksDB быстрее PgSQL дрянных хранилок
ClickHouse - колоночная база.
RocksDB - встраиваемая библиотека для key-value.Что значит "быстрее"-то?
- Грузины лучше, чем армяне!
- Чем?
- Чем армяне!
Thread pool из коробки тоже нету
>ClickHouse - колоночная база.Это где таблицы с инверсным хранением? Можно подобрать случаи, когда такой подход лучше, но в общем случае, в нормальной субд, мы находим запись с нужным значением поля и тут же все остальные поля нам доступны в памяти, потому что хранятся вместе. В инверсной бд для каждого значения нужно еще прогуляться , чтобы получить значение, что, понятно, будет медленее.
Таких имен тысячи. Узкоспециализированных продуктов под какой-то тип данных и тип хранения.
ClickHouse разве не append-only?
Он ещё и не совсем ACID. Зато заточен под стат. расчёты по очень-очень "плотно" вливаемым данным. Возможно, ещё складывать некоторые логи подойдёт. Лично я к нему с интересом приглядываюсь (пока).
=
Декларативное партиционирование таблиц: разделяйте ваши данные с лёгкостью
=Эх! Глядишь и на Zabbix'e жить станет попроще.
> =
> Декларативное партиционирование таблиц: разделяйте ваши данные с лёгкостью
> =
> Эх! Глядишь и на Zabbix'e жить станет попроще.Тише-тише, не так скоро! Сначала с 8.3 надо слезьть. //ну, с 9.1, ладно
все равно - чую приближение весны (:
> В модуле file_fdw появилась возможность запуска внешних программ, например, можно импортировать данные в таблицу из сжатого файла, запустив gunzip для распаковкии использовать pgAdmin в качестве эмулятора терминала
https://www.youtube.com/watch?v=b2F-DItXtZs
"Комитом" унитазы моют. А БД -- транзакции ФИКСИРУЮТ.