Издание DB-Engines обновило свой рейтинг популярности СУБД и присудило звание СУБД 2023 года проекту PostgreSQL, который за год продемонстрировал наибольших рост популярности из 417 отслеживаемых систем. Второе место присуждено облачной платформе Databricks, которая за год поднялась с 19 на 17 место в рейтиге, а третье место занял движок Google BigQuery, который поднялся с 21 на 19 место в рейтинге...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60388
Что-то SQLite3 и Metakit4 не любят...
Психически здоровые люди в принципе не должны пользоваться SQLite3 ни в каком виде.
Айфоном пользуешься?
Пользователь скулайта детектед.
Боишься пользователей скулайта?
Этак можно каждый раз пугаться, проходя мимо зеркала.
Сильно лучше, чем "в простых текстовых файлах", как завещали основатели UNIX.
^^ На самом деле, этот комментарий должен был быть в соседней ветке. Акела промахнулся.
SQLite используется браузерами для хранения всех данных. Достаточно здорово?
Лучши показатель худшего при применения.
Предлагаешь рядом с каждым браузером MySQL поднимать?
Помню толи в KDE3, только в KDE4 был какой-то музыкальный проигрыватель с хранением данных в MySQL. Пля какая тормознутая жесть это была.
Да там и сейчас KOrganizer MariaDB использует.
Надо для программы ведения заметок прикрутить Оракл с партициями, кучей индексов, rman по крону запускать.
Ох да... Как-то органайзер искал, решил на этом остановиться, пока на процессы не посмотрел...
https://www.mysql.com/customers/
Да, это Amarok. Серверную СУБД использует для хранения музыкальной коллекции.
Прикол в том, что такие, как ты, никогда не смогут сделать всё то что в прикладном софте делается через SQLite дёшево и сердито, не говоря уже о "лучшем применении", простоте работы с этим, надёжности, производительности, размерах, портабельности...
Нет никакой проблемы навернуть какую-нибудь log-structured хрень на коленке на текстовых файлах в читабельном для человека виде, с транзакциями, контрольными суммами и компакшенами. От SQLite здесь требуется только хранение данных между перезапусками приложения, сами базы мелкие и все данные из них можно грузить сразу в память. Собственно потому log базы для этого отлично подходят и они просты в реализации.
Используется любыми программами, которым не похер на сохранность данных. Браузерам, кстати, похер -- они повреждаются и обнуляются только так, несмотря на скулайт.
Похер как раз скулайту. Потому что он не подходит для данной задачи.
Идеально подходит и обеспечивает абсолютную надёжность и защиту от потери бесценных данных.
не хотел бы тебя огорчать, но обнуляется и повреждается твоя любимая мразила именно потому что вместо sqlite по каким-то них-причинам ее рабы перешли на самодельные xml и нескучные json.(Вот например эта - с которой пишу - не может запомнить размеры окон при перезапуске. Причина хорошо известна, как лечить - никто не знает. Пока эта инфа хранилась в sqlite - все просто работало.)
Лучше бы, конечно, gdbm.
https://www.gnu.org/software/gdbm/ редиректит (302) на https://www.gnu.org.ua/software/gdbm/ , а в РФ блокируют сайты в ua-доменах все подряд, включая gnu.org.ua. Не раз сталкивался с тем, что нужно скачать дейташит, а он зачастую на ua-сайте, ни одного политического сообщения на странице нет - а сайт всё равно заблочен просто за то, что в ua-домене.
https://www.gnu.org/software/gdbm/manual/Copying.html
>This library is free
>GNU dbm (GDBM) is not in the public domain; it is copyrighted and there are restrictions on its distribution/0
>GDBM is currently distributed under the terms of the GNU General Public License, Version 3.
ффтопку.
Специально для тебя есть berkeley db.
Не ной, это одна из реализаций. И никто не запрещает тебе отправлять в неё данные через system. Если прям так хочется воровать чужой код, возьми какую-нибудь cdb, она лицензирована как общественное достояние. Кстати, gdbm надёжнее той же leveldb. Я до сих пор не столкнулся с рандомными уничтожениями файлов (от всего) в ней, что для leveldb обычное дело.
Для этого надо по рынкам смотреть, ведь они тоже неравномерно друг относительно друга растут. И тогда уже смотреть на лидеров конкретного направления.
> Что-то SQLite3Потому что рейтинг в основном учитывает вопросы и обсуждения. Так как функциональность у SQLite крайне мала по сравнению с серверными СУБД, то и обсуждать там особо нечего.
Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно. Поэтому многопользовательность и прочие сложности обеспечения консистентности тут не нужны. В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение. Кому надо покомпактнее без сложных SQL-запросов - тому наверное лучше метакит или вообще LMDB.
>>Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно.Это не так...
Ну попробуйте из двух приложений одновременно писать в одну базу данных SQLite.
Ну вообще можно и делается, но если такой use case не является целевым, то лучше заблокировать базу эксклюзивно, и производительность операций с ней вырастет.
да. имеено поэтому sqlite значительно превосходит в скорости записи и чтения все серверные субд, но не во всех случаях может бытьиспользован
> имеено поэтому sqlite значительно превосходит в скорости записи и чтения все серверные субдПользователи Redis с вами не согласятся.
Бенчмарки в студию. Но только чтобы эти данные вот прям сохранялись, а не "мы тут что-то в память прихранили, но если свет моргнёт, то продолбаем вообще всё, ещё и старые данные развалим"
более того я уверен что sqlite в режиме inmemory уделает redis очень просто )))
`PRAGMA journal_mode = wal2;` и пишите сколько нужно.
> В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение.Ещё один размороженный. Добро пожаловать в 2024-ый, уже 20 лет прошло с твоей заморозки, мир сильно изменился
https://www.sqlite.org/version3.html
https://www.sqlite.org/fileformat.html
>Record Format
>A record contains a header and a body, in that order. The header begins with a single varint which determines the total number of bytes in the header.Для тех кто в танке: каждое значение имеет заголовок с типом, при этом даже если в DDL указан один тип, в ячейку можно записать другой, и база это переварит, а у тебя проблема вылезет при чтении такой записи. Это какой-то полу-BSON, что приводит к оверхеду на каждый элемент. А если у тебя миллиарды этих элементов?
Да ещё значения хранятся в Big Endian, что идиотизм, так как абсолютно все актуальные машины сейчас - это little endian, и вообще придумать использовать big endian - это извращенцем или вредителем быть надо, ибо элементарнейшие действия, в LE получаемые абсолютно бесплатно, в BE требуют кода и знания длины числа. Проблема решается тривиально: выпустить новый формат на основе little endian, выпустить in-place конвертор в оный, просто мапящий всю базу, находящий все куски с числовыми float-полями, какое-то время подержать поддержку в коде самой базы, потом какое-то время добавить автоконвертацию, а потом старый формат вообще дропнуть. Кому надо - сконвертят.
Ну так выпусти!
Тут тебе никто ничего не должен...
Я дажe название подскажу: "SQLiteLE"
Звучит как боль чувачка, который не смог в ORM и нормальные миграции
ORM - это говно, которое имеет смысл использовать только поверх key-value хранилища. Потому что смысл ORM - это просто прозрачное для прогркммиста получение данных по ключу и сохранение данных по ключу, а все операции делаются на стороне приложения. Для этого движок SQLite с индексами, оптимизацией сложных запросов и оверхедом на всё это просто избыточен: сам ORM строить подобные запросы не умеет. SQL используют там, где надо не просто хранить бизнес-данные, но ещё эффективно их выбирать, пересылая только те, что нужны, и модифифировать, избегая ненужных запросов. Поэтому у меня используется ванильный SQLite + ООП-обвязка + мои кастомные запросы, оптимизированные вместе со схемой. Но не ORM.
Не стоит демонизировать орм, это отличная штука на практике. Большинство практических задач решаются только на уровне орм, да и построитель запросов в любом случае необходим. Кроме того, он позволяет сосредоточиться на логике приложения. Просто надо уметь с ним работать. Ну и понимать ограничения (а у каждой реализации будет своя специфика).
>SQLite с индексами, оптимизацией сложных запросов и оверхедом на всё это просто избыточен: сам ORM строить подобные запросы не умеетя не знаю, что у тебя за орм, но нормальный орм всё это умеет, и, кроме того, позволяет всё настроить дополнительно, для уровня базы, при этом, у тебя остаётся уровень орм для интересных вещей, поддержка которых не реализуема эффективно в сикуль
ORM есть смысл использовать только когда совсем не умеешь работать с базами данных
Ок, проблема понятна. Да, неприятная особенность SQLite. Только это не проблема эффективности хранения и отсутствия схемы, а проблема отсутствия ограничений по типу. Хранение тут более-менее эффетивное, но не самое оптимальное. LE или BE для СУБД вообще никакого значения не имеет, считай это особенностью кодирования. СУБД может хранить числа как угодно, хоть всё в VARINT-ах или поколоночном delta кодировании на битах. LE или BE имеет значение толлко когда есть возможность работать с данными прямо из хранилища, SQL СУБД такой фичей не обладают.
вопросы про sqlite просто не попадают в статистику, кроме совсем уж нубов.И те если не после первого попадания то раза с десятого хотя бы уже обычно дальше sqlite.org с ними и не ходят.
А "у меня кончилось место на постгрезовом диске, штаделаааатьпамагиитя" - каждый день по сто тыщ.
Всё ещё лучше чем "мы использовали на проде MS SQL CE и БД перевалила за 4Гб, как жить дальше?".
Про окакл вообще пугающе дофига вопросов (или правильнее читать проблем?)
э... я боюсь даже вводить такой запрос.(ms sql ce - на минуточку, в девичестве "ms sql for windows CE". Для запуска на пда о 64 мегабайтах оперативы.)
> Про окакл вообще пугающе дофига вопросов (или правильнее читать проблем?)
дык - "чтоб денег никому не платить".
Особенно в свете проблем одной интересной страны без международно признанных границ.Пользоваться им без доступа к течнету/otr - такое себе. Т.е. надо понимать что это нифига не коробочный продукт, точнее говоря - для тех кому он на самом деле продается - не может быть коробочного продукта.
Если его вместо mysql использовать - то вряд ли ты осчастливишь статистику такими запросами - он просто будет работать, даже неинтересно.
Уж не потому ли что в одной стране постгрей замещают весь тухлый орацле?
А в чём смысл именно базы Oracle (помню, что у оракла есть какая-то очень крутая энтерпрайзная технология на основе очереди событий, огромной библиотеки обработчиков и с возможностью добавлять собственные блоки, но это, наверное, другая история)?
А, вспомнил, Oracle BPM называется.
>в чём смысл именно базы Oracle
Так забацали же Postgres Pro, добавили в реестр.
И ты сможешь получить такой же саппорт там. Ну, почти такой же!
Так что даже выиграли!
Учитывая последние крупные сокращения в Oracle — как минимум, не проиграли.
Эх, знал бы Ларри, как за него тут переживают, прослезился бы... наверное :)
https://www.datacenterdynamics.com/en/news/oracles-larry-ell.../
Похоже, что undo segments в Oracle DBMS более правильное техническое решение, чем аналог в PG. В Oracle больше отладочных данных для поиска затыков, больше статей по оптимизациям. С другой стороны, в PG больше типов данных, но для счёта денюжек это не фича. В принципе можно жить хорошо и с PG если развивать ИС с нуля на PG. Но миграция может оказаться очень болезненной и проблемной.
> А в чём смысл именно базы Oracleв том что она как правило - работает.
А когда все же приходит с ora006 - можно обратиться в техподдержку и тебе индус популярно объяснит что сравнивать содержимое xml-атрибута вообще говоря можно, но для этого атрибут хотя бы в этом xml должен быть ;-)А если тебе нужна просто реляционная субд - то обычно и mysql достаточно (ну или вовсе sqlite)
И никаких тебе вакуумов которые ну уже совсем окончательно победили и объявили deprecated, но опять что-то помешало.
> А если тебе нужна просто реляционная субд - то обычно и mysql достаточно (ну или вовсе sqlite)Видимо, ни с чем сложнее KDEшных приложений вы дела не имели.
Ничего не понял.>в том что она как правило - работает
SQLite работает. Postgres работает. MariaDB/InnoDB работает. LMDB работает. MongoDB работает. Neo4J работает. Любая успешная база работает. Не вижу в этом аспекте никаких отличий.
>можно обратиться в техподдержку и тебе индус популярно объяснит что сравнивать содержимое xml-атрибута вообще говоря можно, но для этого атрибут хотя бы в этом xml должен быть ;-)
У всех крупных баз есть компании, оказывающие консультации за деньги, зачастую - те же компании, что базу и разрабатывают. Не вижу отличий. Также не понятно, нахрена эти консультации, если такие вещи должен знать сам разраб приложения, использующего базу. А если не знает - всё на StackOverflow есть.
>SQLite работает. Postgres работает. MariaDB/InnoDB работает. LMDB работает. MongoDB работаетДо первого хорошего кабздеца на критичных и очень дорогих карману данных. И тут-то высняется, что будь там оракел, отделались бы испугом, а тут или вообще все в хлам, или многодневное восстановление, а это лямы убытков. Оракелу-то аналогов и нет, по большому счету.
Ну да, точно, оракел же сам Кашпировский зарядил на неломаемость, так что он сохранит ваши данные, даже если датацентр выгорит полностью.
В серверных СУБД есть репликация и это относительно стандартные сетапы. В SQLite нет ничего кроме защиты от краха ПО во время записи в файл бд
Иди хотя бы доки по оракелу почитай, а потом по постгрям всяким, и призадумайся, что такого во оракеле есть, чего нет в постгрях, и зачем вообще это нужно.
Так и знал, что ничего, кроме "бла-бла-бла", от вас, маркетологов, не добиться.
У Oracle есть такая технология, как Flasback Database. Для огромных баз данных - очень полезная штука, если какое-нибудь обновление свалилось и надо восстановиться быстро (несколько минут) к предыдущему состоянию.
Есть разные способы доставки архивных файлов журнала регистрации транзакций (выбирается в зависимости от ценности твоих данных и быстроты сети между основной и резервной базовый данных.
Есть настраиваемые способы контроля при записи блока данных на диск.
Есть recovery manager, который битые блоки, отдельные таблицы может восстанавливать.
Есть возможность записи данных на диск мимо буферов ОС.
И так далее.
Это которая PITR в PG?
Это которые https://www.postgresql.org/docs/11/different-replication-sol... ?
Это не задача БД
pg_probackup?
> Это которая PITR в PG?Это гораздо, на порядки, быстрее, чем PITR. Почему? Потому что у тебя нет необходимости восстанавливать всю БД целиком, а потом накатывать логи до необходимого момента в прошлом. Оракл откатывается по флешбэк-логам. Притом делает это очень-очень быстро. Для террабайтной БД на обычном дисковом массиве такой откат занимает считанные минуты (в зависимости от того, сколько логов после точки восстановления ты успел нагерерить).
> Это которые https://www.postgresql.org/docs/11/different-replication-sol... ?
Нет. Это три основных режима накатки логов на стендбай (физический, а есть ещё логический): синхронный, асинхронный, запись прямо в логи стендбая.
>> Есть настраиваемые способы контроля при записи блока данных на диск.
>Это не задача БДНу конечно, когда этого нет в любимой СУБД - сразу становится "не нужной фичей". :) PG так не умеет, от слова "совсем". Оракл - умеет. И это довольно важная фича, если ты не особо доверяешь своему железу, которое с дисками работает.
> pg_probackup
Он не умеет восстанавливать битые блоки. И это сторонняя программа. RMAN - стандартный инструмент для управления бекапами у Оракла. И он более фичастый.
Пока есть такие "специалисты", у нас будет работа.
> Пока есть такие "специалисты", у нас будет работа.мляя, а НОРМАЛЬНОЙ работы - что, уже совсем нет?!
Вот всю жизнь мечтал выносить горшки за альтернативно-одаренными (прямо в офисе куда их по квотам набирают)
>замещают весь
Любая миграция стоит денег, а банкиры отлично умеют считать деньги.
Естественно, выгоднее будет ничего не мигрировать, а просто поныть и попросить подачек.
Не все банкиры одинаково сообразительны.
Проблема не только в миграции, как таковой. Проблема ещё в технологической ущербности (по сравнению с Ораклом) других СУБД такого же класса.
Орокле в лицензии прописали что им обязаны предоставить доступ на любой объект, включая военный и закрытый город и конечно же они посланы.
Там даже запрещать бесполезно ввиду неприемлемой лицензии.
Протри глаза это Оракл ушел. Ораклом пользовался или даже пользуется даже Центробанк.
Ещё раз, нахрена именно оркал? SQL везде примерно одинаков. За что именно платят оркам сотни нефти за лицензии на базы? Что там такого в этой DBMS, что нет ни у кого другого?
> Ещё раз, нахрена именно оркал? SQL везде примерно одинаков.эксперт опеннета пожаловал.
> За что именно платят оркам сотни нефти за лицензии на базы? Что там такого
вот когда ты это наконец узнаешь - тогда и приходи.
Ну или хотя бы с "примерно одинаковым SQL" разберешься.
> Ещё раз, нахрена именно оркал? SQL везде примерно одинаков. За что именно платят оркам сотни нефти за лицензии на базы? Что там такого в этой DBMS, что нет ни у кого другого?Самые крупные суммы контрактов — соответственно, самые крупные откаты. Оно и в этой стране, и в Европе, и за океаном высоко котируется.
Ещё раз. С Ораклом тебе гораздо проще рулить базами с ценными данными. Просто иной раз на порядок проще. Потому что разработчики Оракла изначально были нацелены на Энтерпрайз решения, а не на сайтик Васяна из Мухосpанска.
До 2022 работал только с Oracle, но потом что-то случилось, и теперь PostgreSQL
На самом деле, процесс шёл с 2014 года, просто с 2022 он ускорился.
Странно ставить в один ряд и сравнивать PostgreSQL и Databricks – on-premise приложение и облачную платформу.
вообще странный рейтинг да
там например есть и Postgres и PostGIS
То, чего не должно быть, на 3-м месте.
Такая же проприетарь, как и оракл.
То, чего не должно быть, на 2-ом месте - php в мире СУДБ
Скорее, аналог JavaScript.
Причём с феерическим отрывом от хламвари, которая на 4.
Всю отбитость этого "рейтинга" демонстрирует его содержимое. Эластиксёрч у вас на 7м месте, а нео4ж на 20м.... ну всё, теперь буду графы эластиком считать (буг0г0г0)
Use caseы разные.
> теперь буду графы эластиком считатьА я даже знаю контору, которая каждое ребро графа сохраняет как документ в эластике (причем версии 2.4).
Там в полной версии таблички Database Model написана. Так что никого ты не переиграл.
Ура, Firebird рванул вверх!
чему Вы радуетесь ?
Что открылся путь из царства теней в мир живых?
Что Firebird рванул вверх, неужели не ясно? Ну ты и тупица!
А что в этом радостного, если не секрет?
Просто других СУБД он в жизни не видел, только эту смог освоить.
> PostgreSQLПо какой-то причине очень любима ентерпрайз галерами.
Подозреваю по причине сложности настройки и эксплутации, можно посадить клиента на поддержку по самые нехочу.
> По какой-то причине очень любима ентерпрайз галерами.По причине бесплатности, за поддержку можно брать как за оракл, но накладных расходов меньше
Так и мускуль бесплатен, но почему-то используется в основном для друпала и вордпресса.
Потому что MySQL криво спроектирован, от реализации SQL и до методов настройки хранилищ. PG это коробочное решение с корректным SQL и с ровно одним рабочим бэкэндом со всеми фичами и плюсами такого подхода. Также PG по фичам и SQLю ближе к другим коммерческим СУБД.
Насколько я помню, у мускуля тоже остался ровно один рабочий бэкенд (не считая одного проприетарного).
PG - это очередная глорификация DBF, поэтому он идёт нафиг.
С таким потрясающим знанием матчасти лесом идёте вы.
Увы и ах.
Ну так чё там, страничную организацию и переиспользование страниц уже добавили, или всё ещё построчник и вакуумы? :D
https://www.opennet.me/opennews/art.shtml?num=59453
Целый навесной бета-костыль, надо же.
Ну, может, такими темпами лет через 20 и станет нормальной DBMS.
дык, эта... статус паблик-беты не меняется уже пол-года. Когда там еще эти пчьолы прилетят - мы уже наверное в рай попадем.
Не уже, а всего лишь. Типичное время вендрения чего-либо это 1-5 лет если апстрим в принципе не против
> Не уже, а всего лишь. Типичное время вендрения чего-либо это 1-5 лет
> если апстрим в принципе не против"так это наверное нескоро" (с)
(ну в смысле можно считать что скорее нет чем есть - а там либо ишак, либо падишах, либо сам Ходжа...)
> Ну так чё там, страничную организацию и переиспользование страниц уже добавилиКак и было отмечено выше, знание матчасти у вас действительно около нулевое (если что, страничная организация данных используется в потсгресе с начала времён).
Ну и как там с переиспользованием?
Почти все реляционные СУБД работают со страницами, а внутри, внезапно, строки. Везде есть переиспользование страниц, везде есть чистка мусора (т.е. VACUUM) и мусор в страницах. Даже многие нереляционные СУБД такие. Проблема PG заключается только в том, что он много мусорит и сильно фрагментирует страницы из-за отсутствия undo сегмента. А именно, всегда добавляет изменённые данные к новым вместо замены.
А ведь да, я таки посмотрел в его on-disk format. И страницы есть, и даже free space map есть.
Вот только толку от этого нет никакого абсолютно. Как можно было умудриться со страничным форматом так залететь - сказать сложно.
Схему на ходу менять можно, или надо все эннадцать терабайт имеющихся данных перелопачивать?
MySQL спроектирован просто офигенно, а инженеры из Oracle потом залечили детские болячки - эти ребята разбираются в базах и хорошо знают свое дело.
Так "офигенно спроектирован" (уже смешно, кстати) или всё-таки имел "детские болячки"?"Во-первых, я кувшин не брала, во-вторых, уже вернула, в-третьих, он уже был с трещиной"
> Подозреваю по причине сложности настройки и эксплутации, можно посадить клиента на поддержку по самые нехочу.Нет, по причине отсутствия опенсорсных конкурентов.
Мускуль — менее универсален, у него узкая ниша лендингов и мелких интернет-магазинов с десятком посетителей в день. За рамками этой ниши начинаются такие сложности, что дешевле на постгрес переехать.
Так и смысл тогда мумкуль брать? Для пары посетителей хватит и дефолтной настройки постгри
> Так и смысл тогда мумкуль брать?Потому что PHP-разработчики, которые за $2/час подпилят друпал под нужды малого бизнеса, обычно умеют подключаться только к мускулю.
> Для пары посетителей хватит и дефолтной настройки постгри
Не все это знают. Типовому PHP-разработчику за $2/час не хочется много думать и что-то учить, ему хочется фигак-фигак и в продакшн.
Какие сложности начинаются с мусклом?Я недавно на нем небольшую базу для аналитики гонял, что-то ок 60Гб. Оно вообще ну очень быстро работает. Что там такое должно быть чтобы мускл затык, а постгря справилась?
Кстати видел эту постгрю в энтерпрайзных галерах. Они умудряются её реально тормозить на десятках и сотнях запросов, потому что DB Инженер - это видимо уже немодно и ненужно.
Кстати, это вы тот PHP-разработчик, который допиливает друпал на $2/час?
Нет.Я PHP в его лучшие годы не трогал. Концепцию смеси серверного кода с html разметкой считаю ужасной, и не безопасной.
Если работать 24 часа в день, то нормально :D
> Я недавно на нем небольшую базу для аналитики гонял, что-то ок 60Гб. Оно вообще ну очень быстро работает. Что там такое должно быть чтобы мускл затык, а постгря справилась?Использовать OLTP для аналитики — уже многое о вас говорит.
Наверное, "ну очень быстро" — это когда запрос отрабатывает за выходные?
> Использовать OLTP для аналитики — уже многое о вас говорит.Если оно работает, и каши не просит - то всё отлично просто.
Перестанет хватать - разверну что-то более серьездное. Но не постгрю.> Наверное, "ну очень быстро" — это когда запрос отрабатывает за выходные?
За доли секунды.
Вообще когда я стат анализом занимался, у нас система на нек сценариях по пол дня думала, в штатах жлобились серверу выделить больше памяти, и оно несщадно свопало. Не велика беда.
- "Упрямство - достоинство ослов"
Ну вот например:https://diginomica.com/look-servicenow-managing-85000-databa...
Вроде всё отлично у них за пределами 10 посетителей в день.
На самом деле, при таких нагрузках у mariadb были проблемы. У меня несколько сотен тысяч баз, и были баги, на которые делал багрепорты. К счастью, все эти багрепорты уже достаточно давно закрыты. Но подебажить пришлось основательно, чтобы разработчики смогли найти причины.
На самом деле у MySQL намного больше универсальности чем ожидается. У неё несколько моделей хранения и можно для каждой таблицы выбрать разную. Настоящие физические кластерные индексы. В PostgreSQL же только одна модель хранения, на которую все вечно жалуются что она пухнет. Вот когда добавят минимум ZHeap, тогда и можно говорить об универсальности. Так что популярность PostgreSQL не связана с универсальностью. Скорее с расширяемостью, соблюдением стандартов, скоростью развития.
^ О, ловите php-шника за $2/час
> О, ловите php-шника за $2/часПоймал тебя дорогой. Полезай в мешок.
Ты сам ответил на свой вопрос. Универсальность это плохо.
Странные ваши суждения, работаю и с mysql и с pg. Базы занимают терабайты Использую для разных вещей просто потому, что у них разная архитектура и есть места, где pg выигрывает, есть и где mysql. Но в общем-то, с большинством данных они справляются примерно одинаково. Если, конечно, структуру нормальный инженер проектировал.
> с большинством данных они справляются примерно одинаковоС вами я могу только солглашаться. Всегда интересно послушать мнение профессиорнала.
> Если, конечно, структуру нормальный инженер проектировал.
Абсолютно с вами согласен.
> Странные ваши суждения
Ну, я не профи в базах данных. Говорю только то, что наблюдаю сам.
Вижу повышенную любовь к постгре у IT галер (в особо извращенном хоррор жанре, с датабейс микросервис и транзакционал датабейс микросервис)Так как считаю, что, в производительности большой разницы нет при правильной настройке, то, предпологаю, что это конкретно связанно со сложностью поддержки и внедрения.
Возможно связь иная, возможно какие-то стандартные курсы девопсов учат кокнретно постгре. Может у постгри какой-то особо удобный докер образ. А может это связанно с наличием кучи расширений к постгре на которые завязанны какие-то старндартные ентерпрайз решения.
А может это деформация тех галер о которых мне известно.Для меня БД - всегда была вспомогательным интрументом. Как-то смотрел на PG но обнаружил путь от "установил пакет" до "подключился и работаешь" слишком сложным.
Когда-то давно работал немного с Ораклом и МС(в рамках дотнета), но для себя быстро перешёл на мускл и теперь Марию. Оно просто работает сразу, в моём опыте. Причём отлично, удалось избежать новомодных timeseries баз. Сжатие страниц? то-же работает отлично, для моих нужд самое оно. По моему в PG аналогичного механизма нет?
> Как-то смотрел на PG но обнаружил путь от "установил пакет" до "подключился и работаешь" слишком сложным.Весьма наглядная иллюстрация тезиса
> Типовому PHP-разработчику за $2/час не хочется много думать и что-то учить, ему хочется фигак-фигак и в продакшн.
Причем, в отсутствие особых требований этот путь может быть нулевым, так как постгрес очень неплохо работает с настройками по умолчанию.
PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL. Лучше поддержка разных типов данных JSON, массивов, енумов. Больше типов индексов, есть частичные, функциональные, индексы для геометрических типов данных. Продвинутое управление ролями, даже есть row level security. Так что плюсы в использовании PostgreSQL есть.
Ну ок, повысим до php-шника за $8/час
Все эти плюшки нужны только если тащите логику приложения в слой хранения данных.
Обычно принято дублировать логику. То есть она и в базе, и в приложении. Зачем этот БДСМ нужен, каждый ответит для себя сам.
У кого-то это способ защиты от написанного джунами кода, у кого-то одержимость контролем всего и вся.
Да, а потом будем тянуть тысячи строк в браузер, чтобы по новой изобрести алгоритмы сортировки и джойнов. Не всегда с базой работает только одно приложение. Ещё есть тестировщики и разработчики, которые могут напрямую в бд вставить что-то. И что в каждое приложение добавлять логику ограничений, проверки уникальности, внешние ключи. Есть схема данных и зачем это тащить в логику приложения. Разгребать потом дубликаты и искать проблемы где забыли добавить внешние ключи намного сложнее, чем мнимый выигрыш от того что бд будет работать быстрее, если мы не будем использовать внешние ключи.
В слое хранения могут быть только данные, а не логика. Логика же это код, выполняемый рядом с данными. И здесь речь идёт не о типах данных и прочих похожих фичах, а о UDF-ках. Нужны они по совершенно очевидной причине: перелопачивание данных прямо в СУБД работает быстрее аналогичной логике на строне клиента (на клиент нужно туда-сюда гонять данные). Этот подход широко используется в биг дате в виде map-reduce и прочих схемах распределённых вычислений. Для OLTP от этого тоже может быть польза на некоторых схемах баз.Сами же дополнительные типы данных и индексы тоже помогают ускорять работу. Обычно дублирования логики не делают т.к. завязка на фичи PG больше никуда не переносима и на другой СУБД уже не получится получить такие же ТТХ эмуляцией логики.
> Лучше поддержка разных типов данных JSONЭто зло.
> PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL.
Разверните.
> индексы для геометрических типов данных.
>JSONК сожалению это жизнь и JSON проник везде. И иногда проще вставить JSON, чем создавать таблицу на 20 колонок в которую будем раскладывать на колонки, и потом собирать в одни объект обратно. Есть простое правило, если с данными работают атомарно (не нужно читать или изменять отдельные поля внутри), то так даже эффективнее хранить в одной колонке.
>check constraint
>Prior to MySQL 8.0.16, CREATE TABLE permits only the following limited version of table CHECK constraint syntax, which is parsed and ignored:
>Before MariaDB 10.2.1 constraint expressions were accepted in the syntax but ignored.До каких-то версий, синтаксис поддерживался, но по факту ничего не происходило. Разве можно такой СУБД пользоваться, которая так легкомысленно к стандарту относится. Деление на ноль даёт NULL. Ещё позволяет указывать в SELECT колонки которых нет в GROUP BY или агрегатные функции. С одной стороны может удобно, с другой может выдать значение из любой строки.
Не знаю, можно или нельзя. Я не большой сторонник стандартов ради стандартов. И не знаю насколько им следует например МС или Оракл.Вообще с этим жсоном наверное моя главная проблема в том, что табличная СУБД пытается зачем-то быть объектной, там ещё и графовые движки есть.
Хотя и гонять жейсон по сети в базу и обратно видится идеей довольно странной.
Но это я так, модные молодёжные BD вообще по http работают.
Вообще-то PostgreSQL разрабатывался как объектно-реляционная, не путать с документной, а не просто реляционная. Там можно определять пользовательские типы данных, например валютный тип, где сумма и код валюты лежат в одной колонке, чтобы работать атомарно, и определять функции над новыми типами. Графовым чаще всего нужен свой язык, так как SQL плохо подходит.
Я тоже согласен что молодёжным базам работать по текстовому протоколу, вместо бинарного это менее производительно. Это ж для каждой строки нужно все заголовки колонок передавать, очень неэффективно.
> Есть простое правило, если с данными работают атомарно (не нужно читать или изменять отдельные поля внутри), то так даже эффективнее хранить в одной колонке.Здесь принцип деления совершенно другой: в БД может быть форматная обязательная часть данных и неформатная в виде документа. Раньше были отдельные СУБД для форматных данных с чёткой схемой и специальные документные СУБД. Поле JSON в PG существует для объединения этих двух подходов в реляционной СУБД. Таким образов в колонки по прежнему уходят форматные данные, а документ в JSON. Раньше документ приходилось хранить в виде блоба и декодировать только на клиенте. C JSON можно строить индексты по документам и работать с ним прямо из SQL. Вот и вся магия с JSON полем. Хранить обычные колонки в JSON поле не эффективно.
> C JSON можно строить индексты по документам и работать с ним прямо из SQLЯ про JSON и веду речь. Можно создать индекс, но подход немного в другом. Что если нужно построить индекс по json-колонке, то скорее всего нужно селектить и джойнить, то тогда эффективней вынести её в отдельную настоящую колонку (конечно если у вас микро таблица). А если уж нужно апдейтить json-поле, то тогда это делать почти обязательно, ведь PostgreSQL пока не умеет редактировать на месте и будет копировать, например мегабайтный json, целиком. Если нужно просто: юзер json положил, юзер json целиком прочитал, то jsonb идеально подходит. На заголовки строки и колонки есть накладные расходы, и если колонок много и их не обрабатывают на SQL, то можно замерять и в некоторых случаях может оказаться что их эффективнее хранить виде jsonb. Но в коменте выше было именно иметь в виду атомарный json-объект.
> Использую для разных вещей просто потому, что у них разная архитектура и есть места, где pg выигрывает, есть и где mysql.Прямо даже интересно, в каком месте может выиграть mysql?
миллион inserts/s в базку key-value
>Базы занимают терабайтыНу это не серьёзно, уровень sqlite ведь.
>справляются примерно одинаково
Ну я и говорю, зачем все эти навороты, когда это задачи для sqlite?
>структуру нормальный инженер проектировал
Ну тут не структурой единой, понятное дело, но бездумный sqlite может не показывать достаточной производительности под приличной нагрузкой.
> Ну это не серьёзно, уровень sqlite ведь.Не надо тут, уровень sqlite — не меньше сотни петабайт!
Не уверен, там лимит около 250 терабайт. Правда, я не слышал, чтобы кто-нибудь больше ~20 задействовал, но, очевидно, что запас хороший остаётся при этом.
тебе, наверное, больше подходит решение от ms, т.к. пишешь на шарпе? И почему нас должна интересовать проприетарщина?
Тебе шашечки или ехать?
А куда делись dBase, FoxPro, Clipper? Да они со своим форматом DBF порвут все эти SQL-и по всем параметрам...
Не порвали, поэтому их тут и нет.
Paradox'а тоже нету.
Свой вижуал бэйсик проприетарный выкинуть можете.
Они канули в лету, но что-то мне говорит, что их новая "волна популярности" ещё впереди. Есть мириады мест, где "многопользовательность" нужна сугубо локально, в пределах офиса. Спрашивается, зачем им умопомрачительные по сложности транзакции, блокировки, файловеры, зеркала, когда всё прекрасно работает на уроне 3 конекшенов и SQLite? Другой вопрос, что подход к "файл-ориентированным СУБД" должен быть современный, модульный, масштабный, тогда и реализации появятся очень даже вкусные.
Два и более одновременно работающих пользователя с базой данных в любом случае требуют блокировок и сериализации доступа, а работа с двумя и более таблицами в любом случае требует ACID-транзакций.
В противном случае практически сразу базу запорете.
Не, можно использовать b однопользовательские СУБД, но придется самому реализовывать все алгоритмы "читатели-писатели", семафоры, мьютексы и и прочие сериализационные кунштюки. Но только, если язык вашей субд это позволяет. Инасе придется все операторы вашей СУБД обернуть в функции си или сикрос-крос, чтобы задействовать многопользовательские механизмы posix.
Ну не, не всё так сложно. Вернее, некотрые сложности РСУБД можно избежать.
Классические реляшки опираются на то, что в любой момент есть несколько клиентов, каждый из которых может запустить любую операцию CRUD и каждая операция не должна тормозить. Поэтому приходится выворачиваться на полную катушку со всеми подкапотными хитростями.Для "маленького офиса"(SOHO) мы можем допустить:
1. Клиенты пишут в базу редко и быстро (создание документов, какие-то мелкие логи). Что позволяет блокировать таблицу ДЛЯ ВСЕХ операций без дополнительных трюков. Лок, запись, анлок.
2. Соотв. чтение может ну совсем иногда подтормаживать, но в целом работает быстро - нет никаких "слепков базы", "транзакций чтения" и т.п. Что видит один клиент, видят все.
3. Подразумеваем, что мы работаем в стабильной среде - т.е. есть электричество и никто в середине записи не дёрнет рубильник. Собственно, так и работает ЛЮБОЙ современный сервер - как минимум на UPS, как максимум - на генераторе.Зная всё это, можно сильно упростить все операции с таблицами и трансформировать работу с реляционной базой - таблицы останутся реляционными, но метод работы с ними будет как у FoxPro - "мануальный": "Считать все записи таблицы", "пройтись по записям, сохранить в переменной все зарплаты", "взять запись, найти записи в другой таблице, зависящие от этой, удалить".
Это просто как пример операций, НО(!) сложные запросы перестанут быть "сложнодекларативными" - они станут ИМПЕРАТИВНЫМИ (что сильно упростит код программиста для алгоритмически тривиальных задач а-ля "найти все города, где люди выше среднего и в музыке любят рок").
У постгреса все хорошо:* опенсорс
* нормальная лицензия, которая позволяет без проблем делать облачные решения (привет, монго)
* проверена временем и нагрузками
* есть специалисты
* для любителей обмазаться json все есть
* что не маловажно для РФ, что postgrespro входит в Единый реестр, имеет сертификат ФСТЭК
Забыл добавить* дока отличная
* расшираяемость отличная
* написана на божественной сишечке
У PostgreSQL настолько все замечательно, что Google год назад получили прирост производительности в 100 (sic!) раз на ровном месте, просто переписав там слой хранения данных. Называется AlloyDB.Существует масса паразитических контор, которые льют в уши насколько PG весь такой бесплатный Open Source, а потом стригут с бизнеса бабло за пропитанные патчи, без которых эта шарманка толком не работает.
> Называется AlloyDB.и работает только в специфическом use case гугля.
Как обычно.Ты бы мог так же ускорить oracle, если бы переписал его слой хранения исключительно под свою любимую key-value - но они не дадут тебе такой возможности.
> Существует масса паразитических контор, которые льют в уши насколько PG весь такой бесплатный
> Open Source, а потом стригут с бизнеса бабло за пропитанные патчи, без которых эта шарманка
> толком не работает.вот видишь - конь-куренция! А у орацла - контора одна, и другого источника патчей у тебя нет.
А без них шарманка тоже не очень. И еще и с паспортом неправильной страны сразу следом за кораблем отправляют.Но проблема что сколько ту опенсорсную поделку не корми - у орацла все равно и толще и длиннее.
И vacuum почему-то не нужон.
> работает только в специфическом use case гугля.Отлично работает, так что остальным остаётся только завидовать.
> вот видишь - конь-куренция! А у орацла - контора одна, и другого источника патчей у тебя нет
PG под разными предлогами отказываются принимать патчи, исправляющие реальные проблемы. По всей видимости, чтобы случайно не поломать кормящийся на этом бизнес. Конкуренция, ага.
Оракл в ноябре начали предлагать допиленный PG в качестве опции в своем клауде (OCI).
Короче, хотите нормальный PG - платите.
Ага, отказываются принимать патчи от таких знатоков как ты? Лечашие одну проблему и создающие десяток других? Нуну..
Я не понимаю, почему плебеи вроде вас (в самом прямом ИТ-смысле как "люди, крутящиеся вокруг самых дешевейших решений") рассуждают о Гугле? Кто вы и кто они - не чувствуете разницу? Гугл, M$, Oracle, Amazon... да даже Stack Overflow НАМНОГО круче, крупнее и мощнее любых ваших проектов. Соотв. с вашей позиции вообще нельзя ничего примерять на себя из того, что творят "столпы ИТ". Ваши два филиала бухгалтерии ПРЕКРАСНО справятся под любой из современных СУБД, нет даже никакого смысла спорить. Кому по вкусу PG - ради бога, ставьте, ОН ТОЖЕ РАБОТАЕТ. Вам гугловские патчи точно не нужны.
> Кому по вкусу PG - ради бога, ставьте, ОН ТОЖЕ РАБОТАЕТ. Вам гугловские патчи точно не нужны.Например. В PG есть счётчик транзакций (XID), который постоянно увеличивается. Когда он переполняется, то вся база встаёт раком. Сбрасывается запуском Vacuum. Он тоже нагибает базу, но временно. В опенсорсной версии размер счетчика 32bit и вам нужен периодический vacuum и как следствие - даунтаймы. Во всех коммерческих форках он уже давно 64 bit (мне кажется это первое, что сразу фиксят), так что с проблемой переполнения вы просто ни когда в жизни не столкнетесь.
Таких приключений по всему PG разбросана тьма. Пока ваш проект уровня студенческой лабораторной - кушайте рекламу и пользуйтесь на здоровье опенсорсной версией. Только не воспринимайте в серьез - в продакшн придется заплатить. Причем косты будут сопоставимы с тем же Ораклом.
Увы, долго постгрес не использовал вообще - у меня пока пет-проекты на нём. Но это не отменяет моих слов - у БОЛЬШИХ компаний проблемы вообще несопоставимы с очередным наколенным "Склад-33". А если счётчик транзакций можно перезапустить остановкой сервера, то скорее всего так и будет. Ну то есть для большинства компаний Постгрес - вполне работающая вещь. На крайняк - возьмут MS SQL, не сильно дорогая вещь (вот я с ним во весь рост писал!).
Все так хорошо, что его надо постоянно навязывать и писать в интернете проповеди о его превосходстве.
То-то все комментарии здесь забиты проповедями про "замечательный mysql", про его простую и прекрасную архитектуру, но без конкретики и вообще подозрительно напоминающие маркетинговую лапшу.
Никогда такого не слышал. Любые топики про постгрес прекрасно обходятся тем, что люди УЖЕ используют Постгрес и им ДОВОЛЬНЫ. Самая агитутская технология в ИТ - это раст. ВЕЗДЕ где можно влезают со своим недоязыком и постоянно капают в уши "работой с памятью". Можно подумать, это единственная проблема софта!
> Все так хорошо, что его надо постоянно навязывать и писать в интернете
> проповеди о его превосходстве.Путаешь с растом. Постгресу реклама не нужна.
>что не маловажно для РФ, что postgrespro входит в Единый реестр, имеет сертификат ФСТЭКты не поверишь, монго в нем тоже есть (под каким-то клованским названием типа аурадб чтоли). правда они настолько не парились и не палились, что даже имена прог (mongodump итд) не переименовывали )
Mysql лучше уже тем, что проще. И она работает. Большая часть претензий к ней из времён myisam по умолчанию. То есть было актуально двадцать лет назад.
Да, у большинства пихающих постгрю везде нет и не будет таких данных, чтобы она была прямо необходима. Берут на вырост, чтобы показать главным образом себе, какие они крутые специалисты.
Берут на вырост чтобы не заниматься лишней миграцией из майсикуэль в постгресс.
> Mysql лучше уже тем, что проще. И она работает.По обоим критериям проигрывает постгресу.
> PostgreSQL названА СУБД
> PostgreSQL уже признавалАСЬ СУБД годаВспоминаем, как расшифровывается "СУБД".
не нужно додумывать того, чего нет, если бы приписали "СУБД" тогда бы и изменился род."PostgreSQL назван"
"проект PostgreSQL назван"
"СУБД PostgreSQL названа"
"система PostgreSQL названа"Тоже самое с компаниями:
"Компания Canonical опубликовала"
"Canonical опубликовал"
"Mozilla опубликовала"
"Енисей вышел из берегов"
"река Енисей вышла из берегов"
Вы реально не видите слова "СУБД" в моём начальном комменте?
Вы реально не видите отсутствие уточняющего слова СУБД _перед_ PostgreSQL в обсуждаемом тексте?
"PostgreSQL названа системой управления базами данных 2023 года"
По вашему должно быть "АвтоВАЗ названа самой убыточной компанией года", "АвтоВАЗ снова стала российской компанией" и "АвтоВАЗ получила годовой убыток". Ухо не режет? Для вас русский язык точно родной?
> "Canonical опубликовал"
> "Mozilla опубликовала"Миша и Вова заканчиваются на А - значит, их род женский?
И при чем здесь окончание?
Десятилетиями работаю с PHP и MySQL. На всяких работах работал, везде MySQL. Только в одной госконторе были oracle, роstgres да и то частично.
Сочувствую! Так и не поработал на нормальных СУБД... :(
и на нормальном ЯП
Мусор даже не поддерживает пул-потоков из коробки в отличии от МашаДБ.
md5 аутентификация? Вы серьёзно?
Серьезно, мозгов тебе не хватило до kerberos авторизации/аутентификации?
Вопрос к знатокам Postgre.
Есть ли инструмент для восстановления одной конкретной БД на сервере на произвольный момент времени из бекапа без остановки всего инстанса?
Без развлекухи с ручным поднятием временного инстанса PG, восстановления и выгрузки\загрузки дампа.
Ты ща спросил примерно такую фигню: "А можно открыть книгу "Каштанка", пролистать до середины и на следующей странице чтоб были "Мцыри"?". Ну вот как ты без остановки сменишь базу? Вернее, что тебе даст "работающий инстанс", если ему всё равно придётся сбросить ВСЁ и загрузить бэкап как АБСОЛЮТНО НОВУЮ базу? Ты ничего не выйграешь, что с остановкой, что без.
Вопрос в целом таки по делу. Будь WAL свой для каждой БД, такой фокус вполне мог бы прокатить "в лоб".
Но у постгри единое состояние для всех БД одного инстанса. И это, в целом, не самое дурное решение (ресурсы-то общие).Я бы посмотрел в сторону новых механизмов репликации. Там вроде появились логи транзакций. И из них можно вытащить то что M$ продаёт последние 20+ лет. Полный бэкап отдельной БД, плюс инкрементный (транзакции с момента полного бэкапа).
* Возможно даже что у кого-то такое есть готовое. За денюжку.
Понятно, ценой производительности/места на СХД, в силу архитектурных нюансов.** В моих краях N лет назад приняли решение "не выпускать новые проекты под Oracle DB".
Старые мигрировать дурных не нашлось. А так, можно постепенно допиливать под свои кейсы. И делать код с учётом известных особенностей постгри. А не "сделайте мне (на шару) 1:1 как в энтерпрайзе за вагон денег".
Postgres Pro Enterprise Manager уже кто-нибудь использует?
А майкософт уже подключился к "разработке" Postgres ?
Microsoft уже давно сказал, что PostgreSQL Pro Enterprise конкурентоспособная база данных. С учетом того, что появился Postgres Pro Enterprise Manager, как аналог management studio, то мелкомягкие точно не пропустят этот момент.