После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 12. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2024 года...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51604
Мне нравится как статьи здесь всегда начинаются: после года разработки...
Не думал что её могли действительно год разрабатывать? https://www.postgresql.org/support/versioning/
Нет, он просто не думал. Зачем ему такие сложности?
Что лучше, сабж или mysql?
Сильно от задач
Мы сочетаем его с кликхаусом
Можно сказать, что постгрэс самый-самый.
В каких-то случаях самый хороший, в каких-то самый плохой.
А можно пример, в каком psql "самый плохой"? Что-то не приходит ничего на ум в качестве такого примера.
Сабж более навороченный, если привыкнете к сабжу то мускель покажется вам игрушкой.
Так ведь хранилище постгри нефига не лучше TokuDB и MyRocks... Еще и WAL доисторический.
Вместо пула потоков, тред на каждый чих!
MyRocks, как и прочие хранилки на LSM-деревьях, страдают от сильного write amplification, и его превосходство над «доисторическим» WAL совсем не очевидно.Куда интереснее было бы посмотреть на многопользовательскую SQL-базу на базе LMDB, по аналогии с SQLightning для SQLite, тем более что сам LMDB часто сравнивают с RocksDB не в пользу последнего.
MyRocks Есть форк от хитечи и Самсунга, которые не страдают amplification.Самсунг ещё сделал SSD с аппаратной NoSQL на базе rocksdb.
https://blocksandfiles.com/2019/09/05/samsungs-potentially-g.../https://www.anandtech.com/show/14839/samsung-announces-stand...
> Сабж более навороченный, если привыкнете к сабжу то мускель покажется вам игрушкой.Или залепухой для прачечной :-)
За ранее прошу прощения за ламерский вопрос, "Сабж" - это что за СУБД?
Спасибо за ранее.
"Сабж" - оно же "subject" - оно же "тема", те о чем идет речь
И насчет "за ранее" см. тут:
https://russkiiyazyk.ru/orfografiya/pravopisanie/zaranee-kak...
Также у mysql есть свои плюсы. Например, запуститься на любом урезаном vps, нет тормозов при внезапном срабатывании автовакум, некоторые другие (спорные) плюсы.
Также, совершенно согласен, что pgsql имеет свои няшки.
тся, вакуум
не, тут правильно пишется, запуститься, с мягким знаком
тогда было бы неплохо обозначать ударение
нет, не правильно: что делает? - запускается. мягкого знака нет.
имелось ввиду "прийти в запущение" (упадок, заброшенность, запущенность). Причем в данном предложении ("...запуститься...") БД это сделает как-то сама, своими силами :)
Что сделать? Запуститься
> тся, вакуум"плюс мусикла - запуститься на чайнике"
плюшки, ёпт
У Постгреса, к сожалению, такие настройки по умолчанию что он тоже запустится на любом урезанном vps. А тормоза вакуума - это всё сказки от неумеющих настраивать.
Стоковые параметры постгри позволяют запустить его хоть на чайнике, не то, что vps.
> Например, запуститься на любом урезаном vpsКак бы сомнительно. Запуститься на таких VPS может и то и другое. Вопрос только какую нагрузку выдержат. У меня база PostgreSQL умного дома на малинке 3B нормально крутится несколько месяцев. Собираются данные с трёх датчиков температуры и ещё по мелочи. Нагрузки на "сервер" не будет особой, так что выше крыши малины с гигом памяти. Ещё в интернете есть свой сервер. Там 2 ГБ оперативки. Крутится кроме MySQL и PostgreSQL для сайтов ещё и Matrix Synapse. Последний выжрал треть памяти оперативной, но сервер ведёт себя нормально. Опять таки гигантской нагрузки нет. Куда ещё урезать VPS я не знаю. И так копейки стоит. В РФ ещё дешевле можно взять, но там проблемы со связностью.
Сабж рекомендован в Джанго для новых проектов. Так что выбора у некоторых и нет.
Сабж + Джанго этот кейс выглядит слишком ассиметрично.
где-то можно почитать о причине такого выбора?
Собственно разработчики фреймворка в своей книге её рекомендуют.If you're not tied to any legacy system and have the freedom to choose a database back-end, we recommend PostgreSQL, which achives a fine balance between cost, features, speed and stability. (The Definitive Guide to Django, p. 15)
т.е. просто "потому что", жаль.
Django provides support for a number of data types which will only work with PostgreSQL. There is no fundamental reason why (for example) a contrib.mysql module does not exist, except that PostgreSQL has the richest feature set of the supported databases so its users have the most to gain.
https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/
спасибо, теперь уже яснее
Ну собственно у разработчиков тоже были причины. И вон выше дали ссылку. К слову когда Django только вышел они рекомендовали Firebird SQL.
насчет firebird что-то слышал, но меня джанго тогда слабо инетересовал
Я когда выбирал (вообще без знаний) первый раз базу, поставил mysql (уже задумавшись, что же ставить - mysql, марию или перкону), запустил, увидел что оно слушает 3306 без авторизации, и сразу снёс. Поставил постгрес и с тех пор ни разу не пожалел. Потом начитался статей и понял что в mysql многих фичей которые я в постгресе считаю за данное, нет и не предвидится.
> увидел что оно слушает 3306 без авторизации, и сразу снёсЯ сейчас тоже предпочитаю PostgreSQL, но как вы так умудрились поставить MySQL? Сейчас даже root нельзя зайти через TCP/IP во многих инсталляциях, только через Unix-сокет. Да и слушает она обычно на 127.0.0.1. Так что доступ извне ещё открыть надо.
Ахаха, какое ламерство
Скажите,а в mysql, поддержку баз данных добавили или все так-же по старинке без нее ?
Mysql 8 уже можно назвать базой данных.Гвозди, которыми системные словари были прибиты к MyISAM, отдрали, операции с ними теперь атомарные. CTE и Window functions завезли. Cost based оптимизатор завезли.
Транзакции для DDL пока не работают, но это дело времени, для этого все уже есть.
да, над 8 хорошо поработали.
забавно как все пиарили марию, а по факту основную работу, а не рюшечки, сделали в ваниле в оракле.
Оракл головного мозга - страшная болезнь.
> Что лучше, сабж или mysql?Если просто поиграться или поставить какой-нибудь phpbb, wordpress или ещё что-то, то проще MySQL.Да и phpMyAdmin для не специалистов в БД очень поможет.
А если что-то серьёзное или с опытом работы с БД, то лучше PostgreSQL.
Если в боевом режиме нужен MVCC тогда Слон. Иначе и Дельфина достаточно.
master-master репликацию так и не завезли?
Продолжают обещать с 10й,пора забыть.
Вас кто-то обманул, никаких планов по реализации мультимастера в ядре postgres никогда не было и нет.
multimaster поможет превратить ваши данные в мусор.
Ответ в духе нет и не надо. Но ведь надо. Галера, кстати, справляется.
Так галера это не mysql, это стороннее решение, сторонних мультимастеров и для postgres несколько штук.
Я уже устал ждать когда она появится. Пользовался BDR - не понравилось в итоге.
master-master есть в Slony, если очень хочется
Кто мешает использовать логическую репликацию?
Часто, но не всегда, здравый смысл мешает её использовать.
> Часто, но не всегда, здравый смысл мешает её использовать.раскройте свою мысль - какие проблемы с логической репликацией в PostgreSQL ?
Если коротко:
- Tables must have the same full qualified name between publication and subscription.
- Tables must have primary key or unique key
- Mutual (bi-directional) Replication is not supported
- Does not replicate schema/DDL
- Does not replicate sequences
- Does not replicate TRUNCATE
- Does not replicate Large Objects
- Subscriptions can have more columns or different order of columns, but the types and column names must match between Publication and Subscription.
- Superuser privileges to add all tables
- You cannot stream over to the same host (subscription will get locked).
Не поддерживает восстановление после переключения источника на резерв (promote standby). Слоты необходимые для логической репликации не реплицируются на standby и на нём отсутствуют.Не поддерживает восстановление после переключения приёмника на резерв (promote standby). Сдвинуть слот назад, даже если нужные WAL есть — нельзя.
Все эти проблемы можно обойти или решить, но это требует как минимум разработки и программирования вспомогательной обвязки вокруг postgres, не все к этому готовы.
Какой нахрен master-master в sql? Для мультимастера подходят только специальные kv хранилища со специально навороченной для этого логикой, включающей прежде всего conflict resolution. И то не для каждого приложения это всё вообще подойдёт.
Microsoft SQL server ?
> master-master репликацию так и не завезли?Для этого же сделан PostgresXL
Я кстати его тестировал на 3-х нодах. Работает, но нужно понимать его архитектуру
>> master-master репликацию так и не завезли?
> Для этого же сделан PostgresXL
> Я кстати его тестировал на 3-х нодах. Работает, но нужно понимать его
> архитектуруСотни форков pgsql достали
Мультимастер для полноценного ACID - это сложная штука, от CAP-теоремы не спрячешься, чем-то придется жертвовать. Синхронный мультимастер - это большой тормоз, асинхронный - это eventual consistency со всеми следствиями. Если никак без этого жить нельзя - есть сторонние решения, построенные на logical streaming, тот же BDR.
Интересно, те, кто ждут мультимастер-синхронизацию в SQL-базе данных, он как это себе представляют.Вот есть два мастера, между ними есть связь и запросы, попавшие на любой из серверов, выполняются на обоих.
Вот опять есть два мастера, но между ними связь отвалилась. Часть запросов выполняются на одном мастере, часть - на другом. На одном сервере пишется, что у Васи на счету стало 10 рублей. На другом сервере пишется, что на счету у Васи стало 100 рублей. И вот связь между мастерами появляется. Информация с какого из серверов должна перезаписать изменения на другом? Сколько рублей должно быть на счету у Васи?
Подобные вещи можно реализовать только при соответствующем проектировании приложения. Оно должно уметь определять, какая часть данных настоящее время может быть не доступна. Доступные же данные могут быть как подтверждёнными - просинхронизированными на все узлы, так и изменёнными только локально. На основе такой информации приложение должно делать выводы - насколько эта информация годится для определённого рода выводов.
Никак не представляют. Они, как моя дочка, "Хочу конфет, но не хочу диатеза".
В этом узле изменения пишутся на Счету Васи а счет Пети синхронизируется. На другом узле изменения приходят на счету Пети , а счет Васи синхронизируется.
Это шардинг, его можно на любой базе сделать, мультимастер для этого не нужен.
Мастер-мастер куда-то "завести" в принципе невозможно. Потому что нужно прописывать, самому, логику разрешения коллизий в модели в этом случае.
Long Live PostgreSQL
Пакеты и undo так и не завезли?
А их везли?
А чего там везти? Не обязательно как в оракле, можно одним текстом с модификаторами паблик приват. Как два пальца...
Если одним текстом, то это extenson и они есть.
Что-то вроде Сегментов отката уже с 11-той есть. Но, конечно, не в виде копии решения Оракла, где в Откат пишут инструкции как вернуть блок в исходное состояние, а просто теперь исторические записи не хранятся вместе с актуальными, а выкидываются в отдельную кучу. Как в МСе, приблизительно, если включить поддержку MVCC.
Вы это использовали в реальности в "PostgreSQL 11"? или читали концепт на wiki?
Я пробовал. Нормально работает. Но никаких плюсов я не увидел. Но и минусов тоже.
Господа, насколько эффективно в Слоне работает пересечение индексов?Дано: гигантская таблица (за миллиард записей), по 20 столбцам созданы отдельные индексы. Кардинальность у каждого очень низкая. Но сочетание нескольких полей обычно имеет от 0 до 50 рядов. Комбинированные индексы делать нельзя.
Слон будет быстро искать в таких условиях? За единицы секунд хотя бы.
Нормально, особенно если ему помочь: настроить статистику (пошаманить с настройками ANALYZE, где-нужно объявить зависимости между столбцами -- https://postgrespro.ru/docs/postgresql/11/sql-createstatistics).Желательно включить HugePages, увеличить shared_buffers, включить многопоточность (max_worker_processes, max_parallel_workers_per_gather, ...) можно добавить pg_prewarm чтобы не тратиться на излишнее IO,..
Большая проблема постгреса -- очень слабая конфигурация по-умолчанию + очень сложная конфигурация для новичка.
---
В некоторых случая может сильно помочь секционирование. Но не в случае с 20 индексами с большой вариативностью запросов.
Конфигурация сложна ровно настолько, насколько сложна сама СУБД. Зато ничего от пользователя не прячут.И, да, в mysql с необходимостью знать числовые значения innodb-констант ничем не проще.
Спасибо!
А зачем для работы с денормализованными данными использовать реляционную СУБД? Она не для этого. Разбейте на 20-ть отношений, каждое проиндексируйте и join-ами. В МС можно было бы сразу кластерный индекс использовать, а в Слоне нужно создавать дополнительный индекс к отношению.
В Слоне нет таблиц. Есть только куча. Кучу, в принципе, можно прозрачно секционировать, но, опять же, каждая секция будет кучей (индекс никогда не смешивается с данными).
Дальше. Не буду интересоваться зачем так, но я правильно понял -- по каждому из 20 свойств создано по одному индексу ровно из одного свойства? Причём кардинальность каждого такого индекса мала. Но если сделать индекс по нескольким полям, то при миллиарде записей, кардинальность может достигать (аж!!!) 50-ти? 50-сят на миллиард, мягко скажем, тоже высокой кардинальностью не назовёшь.
Если на шпинделях, то Слон сильно сольёт МСу и Ораклу; на ссд -- разница будет существенной, но не такой вопиющей. Но это моё частное мнение.
>Но если сделать индекс по нескольким полям, то при миллиарде записей, кардинальность может достигать 50-тиНет. Поиск по нескольким полям выдаст 0-50 рядов из миллиарда записей.
Составной индекс по нескольким полям делаешь - ищет за милисекунды.
Но все комбинации полей составными индексами не закроешь.
Сейчас всё в монге, там, похоже вообще крутилок нет на эту тему.
Интересуюсь, у кого есть шансы задачу решить.Орацле обычно без приставленного к нему седовласого ДБА с ворохом сертификатов работает очень фигово. Слон, видимо, посередине...
Нет, настройка Слона значительно менее предсказуемый процесс, чем настройка Оракла. Хотя и тот и другой настраивать не сказал бы, что сложно. Просто консультирование по Ораклу отдельный бизнес, со своими маркетинговыми мифами-ужастиками. А так, Оракл прост и понятен. Куда понятней, чем тот же МС.
Задача тривиальная. Всё в итоге упрётся в эффективность алгоритмов подлежащей системы хранения, а не в конкретную СУБД.
Может заюзать более подходящий индекс, типа bloom?
Подведите, пожалуйста, libpq под С-стандарт.
Например, сделать pq_connect_db вместо PQconnectdb.
Ну напихайте пачку #define-ов, если так коробит :)
C-стандарт никак не регламентирует именование функций.