После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 13. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2025 года...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53774
Замечательная БД. Лучшая в мире, имхо.
Постгря объективно лучшая, так что имхо тут лишнее
Ну, это вы за своё имхо так говорите! :)
Постгрес, там «с» в конце.
«с» не в конце, а в начале SQL
А в слове "прогресс" тоже в начале? Или это такой троллинг? Вообще надо секту "постгрЭ" законожательно запретить как сделали с АУЕ.
> А в слове "прогресс" тоже в начале?Если ты заметил, в "прогресс" нет суффикса SQL.
Нет, https://ru.wikipedia.org/wiki/PostgreSQLСлово postgres образовано от "Post Ingres" и изначально никакого SQL он не поддерживал.
После реализации SQL авторы решили что название postgres95 не очень и что будет прикольно написать "PostgresSQL", а ещё круче — убрав дубль S, "PostgreSQL" и произносить «Пост-Грэс-Кью-Эл», о чём теперь жалеют и считают что это было ошибкой, потому что при увеличении сообщества приходится всё время объяснять новичкам правильное название базы :-)
https://www.postgresql.org/docs/current/history.html#AEN187
Berkley POSTGRES (с 1986) → Postgres95 (с 1994) → PostgreSQL (с 1996).
«Many people continue to refer to PostgreSQL as “Postgres” (now rarely in all capital letters) because of tradition or because it is easier to pronounce. This usage is widely accepted as a nickname or alias.» ←→ «Многие продолжают говорить Postgres, ибо традиция и произносимее. Приемлимость «Postgres» в качестве синонима высока.»
Когда-то думали переименовать в Postgres: https://wiki.postgresql.org/wiki/Postgres
Но консенсуса не было: https://www.postgresql.org/about/policies/project-name/
> The name Postgres is an accepted alias for the PostgreSQL project. However it is an alias or nickname and is not the official name of the project. Per Dave Page, PostgreSQL Core Team:
> Following recent discussions on a name change for the project, it has become clear that consensus within the community will never be reached. In light of this, the core team have discussed the matter in depth and decided that the project shall continue to use the name PostgreSQL, but accept the use of Postgres as an alias.С употреблением Britain и Great Britain то же самое (но там Great добавили, чтобы остров Britain с Britanny не перепутать, оба от лат. Brittania).
Ага, настолько классная что Uber с неё свинтил на MySQL + свой напилиник по понятным причинам...
Свой напильник можно было и в постгресе сделать, это чисто политическое решение, о миграции.
Если бы Uber провёл то самое исследование производительности на этапе проектирования структуры базы, а не когда все уперлось в обновление индексов, можно было бы и никуда не валить, а спроектировать базу с применением головного мозга. У них там была таблица с индексом почти на каждое поле, и она обновлялась по сто раз в секунду. Это им ещё повезло, что внутреннее устройство innodb подошло под их кейс, и что они не обновляли primary key (вот тут бы innodb вообще обвалился - там pk=oid грубо говоря). Но эта проблема ещё валидная (и с тех пор в ее в pg не то, чтобы целиком решили, но существенно смягчили), все остальное вообще из разряда «не осилили».
Там не только проблема со вторичными индексами была, с VACUUM проблема более-менее тоже актуальная на больших объёмах данных при постоянной перезаписи.
Проблема там была только с мозгами и откатами. Устроить миграцию MySQL - PostreSQL - MySQL без нагрузочного тестирования, на шару - это надо быть или идиотом, или умным распильщиком.
Про вакуум в постгресе знают вроде вообще все, даже те, кто запросов сложнее select * from table в свой жизни ни разу не писал. Кроме разработчиков Убера, видимо, для которых это оказалось новостью когда все прилегло.
Как может быть лучше субд у которой это говновакуум вообще существует?А дебильные имена объектов в UPPERCASE?
НаверноеЕстьРазница?
ИЛИВСЕТАКИНИКАКОЙРАЗНИЦЫНЕТ?
В postgres регистронезависимые имена.
> В postgres регистронезависимые имена.но регистр он не запоминает.. в отличии от MySQL
можно смело забыть про PascalCase
Куда там Oracle, Ms SQL Server и IBM DB2, да? Это просто мальчики для биться по сравнению с вакуумным Postgre? Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка?
Правильно писать Postgres
Лучший ответ на заданный вопрос )
Да там и с русским проблема, не то что с названиями.
Правильно - рисовать слоника )
А при чём здесь РНР?
Аноны, вы вконец ослепли??
https://www.postgresql.org/media/img/about/press/elephant.png
Это логотип!
Чтоб продавать постгре вместо оракла.Но на больших БД - поддержка постгри дороже оракловской.
Очевидно что вы не разбираетесь в теме раз даже не знаете как база правильно называется :-)
>Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка?За тем, что Postgres отжал у Oracle рынок, а это добивает последних.
Я еще в 2011-2012 RBC переводил с Oracle на Postgres, экономия была огромной как по лицензиям так и по простоте поддержки и стоимости обслуживания.
Чем легче перенести код с PL/SQL на PL/pgsql - тем больше пользователей это сделают.
А практическая бесшовная поддержка иных языков - очень сильное конкурентное преимущество. После длительного общения с MS по поводу активного использования R в MS SQL, они сами рекомендовали перейти на PostgreSQL. Производительность выросла на порядок!
Если конкретней, то при необходимости нескольких миллионов вызовов функций на R при обработке данных, вместо 14 часов на MS SQL стали укладываться в 70 минут на PostgreSQL на том же сервере.
Кстати, как там в Postgre с партиционированием, завезли полноценное или еще на 5 лет отставили?
Для тех, кто тогда ходил под стол, сообщаю, что партиционированию в Oracle больше 20 лет.
На ручном приводе я ещё в 2003 партицирование делал пользуясь наследованием, которое вроде ещё с 80х в постгресе.Но, конечно, это было не так удобно, как полностью поддержанное самой базой.
В postgres, да, завезли.
Давно уже есть.
С десятой версии вроде.
Это только в энтерпрайзной версии, которая многие миллионы стоит, которую только супер корпорации позволить себе могут. В MSSQL больше фич за 300к.
Лучшая в мире БД для лучшего в мире юзкейса
>Лучшая в мире, имхо.JSON там считай что нет. Соответственно, лучшая средневековая СУБД.
В Монге, кстати, уже давно и транзакции завезли (хотя они по прежнему не нужны в 98% случаев).
В монге так реализовали транзакции, что и оставшиеся 2% не выйдет использовать. Они работают только в реплик-сетах, и при этом не работают на шардированных коллекциях (обещали позднее сделать). А без шардирования монга полезна в редких случаях.
>Они работают только в реплик-сетахЯ вообще ХЗ как может быть невасян СУБД без реплик... учитывая время разворачивания бэкапа на несколько ТБ. Любое железо смертно.
А про шардирование, вот прямо никак без него? У меня базы по 1-3ТБ нормально ворочаются без него...
Так что "оставшиеся 2% не выйдет использовать" это false.
> Я вообще ХЗ как может быть невасян СУБД без реплик... учитывая время
> разворачивания бэкапа на несколько ТБ. Любое железо смертно.Если придираться к словам, то репликация - это не то же самое что бекап, и не заменяет его.
Необходимость поднимать реплик-сет, только ради транзакций, доставляет немного хлопот в процессе разработки. С классическими RDB достаточно запустить их в минимальной конфигурации и весь функционал будет работать.
> А про шардирование, вот прямо никак без него? У меня базы по
> 1-3ТБ нормально ворочаются без него...Думаю и другие базы данных вполне будут нормально ворочаться на таких объёмах без "шардирования".
Но в случае с монгой, простое шардирование из коробки - это главная киллер-фича. Если вам оно не нужно, то необходимость использовать именно MongoDB чаще всего сомнительна.
>Если придираться к словам-"реплики редко нужны"
-нет, реплики нужны всегда, т.к. время разворачивания бэкапа несколько дней
-репликация - это не то же самое что бекап, и не заменяет егохрень пишешь...
"простое шардирование из коробки - это главная киллер-фича"ой, мля, ну всё, срочно побежал монгу менять на всех проектах, т.к. я внезапно не использую киллер-фичу
> хрень пишешь...В чём хрень? Если у тебя приложение (или хакеры) испоганит данные в базе, то эти изменения будут во всех репликах базы очень быстро. Т.е. репликация ни каким образом не позволит тебе откатить состояние базы на какой-то момент в прошлом, когда всё было нормально. Для такого нужен бекап. Поэтому я и написал, что репликация не заменяет бекапы.
> ой, мля, ну всё, срочно побежал монгу менять на всех проектах, т.к.
> я внезапно не использую киллер-фичуЯ и не прошу тебя отказываться от Монги в уже написанном проекте (сам уже 8 лет пилю такой). Я говорил исключительно про выбор базы данных для ещё ненаписанного приложения.
> Реализована концепция заслуживающих доверия дополненийЖдём появления магазина дополнений, которые можно ставить в один клик. А то несовременный он какой-то, этот Постгрес.
Куда же без монетизации и монетизации на монетизацию?
https://pgxn.org/about/
> https://pgxn.org/about/О, круто! А дыры, дыры-то есть? А то ж дополнение без дыр - это какое-то неполноценное дополнение.
Как напишешь — так и будет.
Неплохая бд под свои цели (тяжелые приложения под реляционрую базу данных). Понятно, что в ряде случаев тот же sqlite, mongodb или redis -- на порядки эффективнее.
Выбирать нужно по техзаданию базу данных, и не париться ;)
sqlite на порядки эффективнее - это интересная идея. Удобнее и компактнее - да, но вот эффективнее...
В РЯДЕ СЛУЧАЕВ эффективнеевнимательнее надо с областью определения утверждений
даже не В РЯДЕ СЛУЧАЕВ, а в В НЕКОТОРЫХ СЛУЧАЯХ.
В исходном утверждении стоит именно в ряде случаев.
Не понимаю, что за мода выкидывать/заменять часть утверждений и затем горячо критиковать получившееся. Это же типичный демагогический прием.
> Не понимаю, что за мода выкидывать/заменять часть утверждений и затем горячо критиковать
> получившееся. Это же типичный демагогический прием.И ну и как тут не ответить? Мой комент был всего лишь поправкой, и с исходным коментом я согласен, что СУБД нужно выбирать исходя из необходимых и достаточных требований (по ТЗ). А далее немного демагогии (можете пропустить) ....
Давайте посмотрим на одно из определений слова Ряд (из вики):"""
Ряд — некоторое, немалое количество, например «ряд стран».
"""Тут пояснения нужны, что словом Ряд можно заменить слово Некоторое? Эту моду придумал не я.
Для записной книжки в телефоне - эффективнее.
> Для записной книжки в телефоне - эффективнее.Таких инсталляций на порядки больше, чем корпоративных БД. Так что правильно говорить о незначительном количестве юзкейсов, в которых sqlite всё ещё уступает Постгресу и Ораклу.
Кстати, не припомню ни одного случая, когда монга была бы именно эффективнее. Проще в разработке и поддержке - да.
В основном в разработке чужого бюджета
Это только потому, видимо, что вам _пока_ не требовалось от СУБД умение работать в состоянии расщепления (Partition Tolerance). Как только это произойдет... ну, тогда вы точно запомните случай, когда MongoDB оказалась более эффективной. =)
Монга первая в мире СУБД с partition tolerance, ога) Мы такое кастомной MySQL proxy делали ещё в бородатом 2006 году.Могна удобна тем, кто не хочет думать, хочет раз-два и в продакшен, mongodb is web scale (c), sharding is a secret ingredient (c). Для стартапов, написанных моральными индусами для развода инвесторов на бабки, самое то.
А если задуматься, то фигня какая-то: schemaless, подразумевающий разреженность, но при этом единственный тип индекса это btree! Инвертированных индексов нет, банальных хешей даже нет, блум фильтров нет, оптимизатора запросов нет, даже планирования запросов как такового нет, населена роботами. И действительно, зачем, давайте делать фуллскан, ведь у нас горизонтально масштабируется, всегда можно докупить ещё серверов... на задачи, где банальный постгрес с одной таблицей вида (id serial PK, data JSONB gin/gist) справится и на одном.
>[оверквотинг удален]
> mongodb is web scale (c), sharding is a secret ingredient (c).
> Для стартапов, написанных моральными индусами для развода инвесторов на бабки, самое
> то.
> А если задуматься, то фигня какая-то: schemaless, подразумевающий разреженность, но при
> этом единственный тип индекса это btree! Инвертированных индексов нет, банальных хешей
> даже нет, блум фильтров нет, оптимизатора запросов нет, даже планирования запросов
> как такового нет, населена роботами. И действительно, зачем, давайте делать фуллскан,
> ведь у нас горизонтально масштабируется, всегда можно докупить ещё серверов... на
> задачи, где банальный постгрес с одной таблицей вида (id serial PK,
> data JSONB gin/gist) справится и на одном.А можно меньше слюней, пены и соплей, и побольше того, что называется "взвешенным мнением технического эксперта". Мы же все-таки на профильном ресурсе, а не форме имени хеллоу ворлд. Договорились? Ну вот и хорошо.
А теперь господин как бэ эксперт, раз уж вы тут ляпнули про JSONB, то дайте в студию хотя бы один запрос, который позволит обновить _отдельный атрибут_ (!) json-документа, сохраненного в поле этого типа. И атрибута не верхнего уровня, потому что это-то как раз PostgreSQL умеет, а где-нибудь поглубже. К примеру, вот есть у вас портянка вида {"aaa" 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 45679}}]}, и нужно обновить "fdrt". Постройте-ка запросик, а? И желательно БЕЗ привлечения тех расширений PostgreSQL, которые пишут умные системные программисты для вполне себе КОММЕРЧЕСКИХ продуктов. Ну, как, справитесь?
Сразу могу сказать, что навряд ли. А вот монга способна этот фокус проделать даже с документами размером в несколько Гб _на любом_ уровне вложенности.
PS Тут уже в треде прозвучало мнение, что каждому инструменту своя предметная область и свои проблемы, которые этот инструмент закрывает. Соглашусь с этим утверждением. У MongoDb своя область, а у PostgreSQL - своя. И прежде чем пытаться померится сами знаете чем, стоит это обстоятельство учесть. И разумно для своих проблем инструмент выбрать.PPS Кстати, "банальные хэши" сто лет в обед в PostgreSQL считаются индексом не рекомендуемым к применению. Внезапно. А все потому что не проходят в WAL. Так что на вашем месте я бы ими не козырял. Не стоит.
О, вот и фанбои подтянулись.> обновить _отдельный атрибут_ (!)
https://www.postgresql.org/docs/13/functions-json.html
Все можно, читай внимательно.> "банальные хэши" сто лет в обед в PostgreSQL считаются индексом не рекомендуемым к применению. Внезапно. А все потому что не проходят в WAL.
Чего?
> https://www.postgresql.org/docs/13/functions-json.html
> Все можно, читай внимательно.Похоже, что читать внимательно стоит как раз вам. Там ни пол-слова нет о том, что можно обновить атрибуты на уровне вложенности больше чем одного, самого первого. Теоретики, такие теоретики.
Еще раз: если вы такой умный, то попробуйте составить запрос, который обновит ровно один атрибут - "fdrt" вот у этого документа, хранящегося в поле типа JSONB:
{
"aaa" 5,
"bbb": [{
"fff": 12345,
"rrrr": {
"fdrt": 45679
}
}]
}Запрос в студию!
>> "банальные хэши" сто лет в обед в PostgreSQL считаются индексом не рекомендуемым к применению. Внезапно. А все потому что не проходят в WAL.
> Чего?Того. В силу определенной архитектуры, операции с индексом типа "hash" не попадают в WAL. Собственно, как я понимаю, единственная причина почему этот тип индекса вообще не приговорили, так это потому, что его использует сам PostgreSQL на системных таблицах. А вот для прикладников его употребление не рекомендовано.
Конкретно в мануалах есть такая информация:
"Операции с хеш-индексами в настоящее время не проходят через WAL, так что после аварийной остановки базы данных может потребоваться перестроить хеш-индексы командой REINDEX. Кроме того, изменения в хеш-индексах после начальной копии не переносятся при потоковой или файловой репликации, так что в последующих запросах они будут давать неправильные ответы. По этим причинам настоятельно рекомендуется не использовать их."
column1 = jsonb_set(column1, '{abbb,0,rrrr,fdrt}','123', true)
опечатался в первом поле: abbb -> bbb
> опечатался в первом поле: abbb -> bbbК сожалению, это немножечко не то.
Я, в свое время, тоже увидел эту функцию и было обрадовался, и как оказалось - зря. Потому что основную проблему - обновление части документа JSON _на_стороне_сервера_ эта функция не решает. Она _просто_ возвращает видоизмененные данные. Причем, я даже не поручусь, что эти изменения не происходят на стороне клиента.
То есть вот эта, трижды клятая в этом треде MongoDB, способна на стороне сервера обновить часть JSON-документа, а PostgreSQL похоже, без доработок-расширений, может обновлять только поле JSONB целиком. Что доставляет проблемы, если ваш документ изрядно большой, допустим в несколько мегабайт. Потому что в этом случае, вам придется весь этот документ забрать по сети на клиент, сделать там его обновление, и потом целиком опять отправить на сервер. А это и дополнительный трафик, и потеря производительности.
похоже что вы очень мало писали запросов для постгрес раз не знаете как обновить значение
не стоит спорить не зная основ
> похоже что вы очень мало писали запросов для постгрес раз не знаете
> как обновить значение
> не стоит спорить не зная основЕще раз: обновить-то можно. Это как раз не проблема. Вопрос где именно обновлять. Потому что обновлять на стороне клиента - контрпродуктивно...
Ладно-ладно, не будем спорить. Но вот когда (и если) вы столкнетесь с ситуацией о которой я говорю (документ в JSONB-поле размером в несколько десятков мегабайт) и начнете просаживать производительность - вспомните тогда меня.
Подумайте зачем сделали целую функцию jsonb_set если мы можем спокойно оперировать json-ом на стороне клиента?
Ладно, люди которые хотели узнать можно ли обновлять jsonb в postgres уже наверняка разобрались, а вам, возможно, хочется найти оправдание почему вы им не пользуетесь
> вам, возможно, хочется найти оправдание почему вы им не пользуетесьКак раз пользовался. Однако имел при этом проблему: при обновлении объемных документов JSON внутри поля типа JSONB сильно падала производительность микросервиса. После того, как микросервис был переписан под работу с монгой, производительность поднялась на пару порядков. Попутно получил профит при обновлении нескольких значений в документе одновременно.
Хотя вот при работе с небольшими документами проблем у PostgreSQL мной замечено не было. Это и заставило меня предположить что операция обновления данных внутри поля типа JSONB полностью или частично выполняется на стороне клиента.
> попробуйте составить запросПопробуйте все же научиться читать. Один раз покажу, дальше сами.
=# select jsonb_set('{
"aaa": 5,
"bbb": [{
"fff": 12345,
"rrrr": {
"fdrt": 45679
}
}]
}'::jsonb, '{"bbb", 0, "rrrr", "fdrt"}'::text[], '100500'::jsonb);jsonb_set
---------------------------------------------------------------
{"aaa": 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 100500}}]}
Update уж сами допишете.> операции с индексом типа "hash" не попадают в WAL
Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно пишется. То ли с 9-й версии, то ли с 10-й.
>[оверквотинг удален]
>
>
> jsonb_set
> ---------------------------------------------------------------
> {"aaa": 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 100500}}]}
> Update уж сами допишете.
>> операции с индексом типа "hash" не попадают в WAL
> Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
> Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно
> пишется. То ли с 9-й версии, то ли с 10-й.А если твой документ мегабайт этак ~дцать, так и будешь тягать его по сети туда-сюда, а? Там где монга _на стороне сервера_ обновит документ из коллекции передавая по сети только определение операции, ты будешь тягать документ _целиком_. Что ты там писал про индусов постом выше? Так вот, с таким подходом, ты именно этот индус и есть.
Где тут таскание по сети? jsonb_set делается на стороне postgresql сервера.
> Где тут таскание по сети? jsonb_set делается на стороне postgresql сервера.
>jsonb_set делается на стороне postgresql сервераНе уверен.
Факт, что PostgreSQL при всех раскладах будет обновлять поле только целиком.
Следовательно ему нужно взять содержимое, обновить его, и положить обратно. Это само по себе затратно. Но этого мало, потому что не известно где именно происходит само обновление. Я думаю все же, что на клиенте. Возможно только частично. И я думаю так же, что все это время сервер держит блокировку, и вот это-то и может объяснить просадку быстродействия, которая начинает наблюдаться, при обновлении полей с объемными JSON-документами внутри....Блин, но вы таки заронили зерно сомнения, да.
Буду копать глубже. Сейчас спорить не буду, - фактов ни "за", ни "против" у меня нет. Возможно отпишусь позже, когда пройдусь сканером трафика, что бы посмотреть что именно отправляется на клиент и обратно.
На сервер отправляется sql-запрос, клиенту приходит результат его выполнения. jsonb_set это постгресовская функция, выполняемая на сервере. Никаких промежуточных штук типа коллбэков в протоколе нет, я когда-то писал свою реализацию постгрес-клиента с нуля (будете смеяться, для php! Но с асинхронкой - еще до того, как появился ReactPHP и подобное, был только pecl/libevent), можете мне поверить на слово :-)Другое дело, что со стороны сервера в mongodb действительно обновление части документа может быть более эффективным - когда постгресу надо распарсить весь jsonb, выполнить jsonb_set и потом сохранить все целиком, в монге могут быть оптимизации. Но я не уверен, что они там есть :-)
Да и в целом производительность поиска меня волнует намного больше, чем производительность обновления.
А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в update переписать не можете.update tablename set fieldname = jsonb_set(fieldname, $1, $2), где $1 = path, $2 = new value.
И кто тут индус?
> А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в
> update переписать не можете.Очень смешно. Шутник.
> И кто тут индус?
Ладно, за "индуса" извините, погорячился.
каким это образом по-вашему update (работающий исключительно на сервере) будет таскать данные на клиента и обратно?P. S. обновление json на десятки мегабайт в любом случае боль. jsonb ЕМНИП никак проблему не решает.
>> операции с индексом типа "hash" не попадают в WAL
> Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
> Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно
> пишется. То ли с 9-й версии, то ли с 10-й.Да, тут я, похоже, не прав. Сейчас сличил версии официальных документаций: начиная с 10-ой версии, они свое грозное предупреждение, которое я процитировал в переводе, убрали. Так что вероятно эта проблема уже решена. Что же... +1 PostgreSQL в таком случае. =) Я в последний раз столкнулся с этой траблой на 9.6 Там она еще была.
> А вот монга способна этот фокус проделать даже с документами размером в несколько ГбМаксимальный размер документа в монге – 16 МБ (ну, если ее не перекомпилять)
Увеличивать эту константу имеет смысл только есть у вас много ОЗУ, потому что она и выбрана-то была, с тем расчетом, что бы документ в ОЗУ поместился с гарантией.Куда проще (и это официально рекомендованный вариант) использовать для хранения GridFS. В этом случае, документ бьется на чанки, что конечно снижает общую производительность, но не так уж и сильно. Но вот документ при этом, может достигать значительно больших размеров.
>когда монга была бы именно эффективнее. Проще в разработке и поддержке - да.учитывая, что у большинства продуктов процесс ДОработки бесконечный, монга уместнее почти всегда. увы и ах...
sqlite удобнее для разработки, но никак не эффективнее
Не сказал бы что он удобнее учитывая что ничего не умеет толком и инструментов под него нет.
У вот таких эффективных пацанчиков, вроде тебя, на мобильниках тоже стоит эффективный PostgreSQL?
Если да, то обращайтесь - у меня друг очень хороший психиатр.
Аналогов то SQLite по сути вообще нет на мобильниках
> У вот таких эффективных пацанчикову "сверх эффективных" даже оракля встречается :)
Что такой агрессивный? Тебя web-разработчики били что ли?А для чего тебе СУБД на смартфоне? Для хранения локальных данных и настроек? Как только к sqlite подцепляется больше одного клиента вся его "эффективность" улетучивается. Поэтому он подходит для прототипирования при разработке, и хранения локальных данных одного приложения, и то в этом случае зачастую подойдет обычное хранилище ключ-значение. Были ещё варианты его применения, но это была совсем экзотика.
А у тебя к адресной книге на телефоне прямо несколько клиентов подключаются. Глупости не говори.Оставим в покое телефоны, посмотри какую какашку с akonadi сделали.
Да, sqlite эфективнее во многих местах, но не в вебне откуда ты пришёл.
приветик ударникам криокамерыhttps://wiki.termux.com/wiki/Postgresql
без рута, регистрации и смс
в моей практике mongodb был менее стабилен под большой нагрузкой.
назови, пожалуста, количество записей в хранилище и частоту обращенийвидел людей, серьёзно считающих 30к записей хайлоадом, которому необходим шардинг
постгря такую мелочь перемалывает без индексов, банальным фулсканом
Не помню. Монги занимали порядка 50-100ГБ данных на штуку, к каждой обращалась пара десятков серверов в реальном времени, т.е. непрерывно, забивая пару мегабит - точно.
Вот storage engines так и не завезли...
Не совсем.Если говорить чуть более абстрактно, то FDW умеет очень много. Может не полноценная замена storage engines, но зато подходит и для других задач.
Если говорить конкретно, то ЕЩЁ не завезли. Они работают над этим.
Это палка о двух концах. Любая абстракция усложняет оптимизацию. А костылями и подпорками, как в MySQL, в постгресе не прокатит, там другая культура разработки (точнее, она там присутствует в отличие от). Тут надо и на елку влезть, и не поцарапаться, это непростая задача. Но исследования ведутся.
Кроме "trusted extension" всё выглядит как нужные и полезные кому-то вещи. А вот эти белые списки дополнений как-то выглядят небезопасно.
Если это такие хорошие и полезные дополнения, то и включите их просто в конфиге по-умолчанию. Кому надо те отключат. Зато нерутовым юзерам не надо будет иметь возможность их включать.
> Список подобных дополнений изначально предопределён и может быть расширен суперпользователем.Тут просто не совсем понятно написано, никаких явных списков там нет, trusted — это просто _флаг в самом файле с описанием extension_.
> включите их просто в конфиге по-умолчанию
Администратор всегда при установке может отредактировать template1 базу сам сделав всё что ему нужно доступным по умолчанию. Если это сделают авторы postgres то потеряется возможность сделать пустую базу, в ней всегда будут какие-то объекты из предложенных вами расширений, потеряется гибкость.
"trusted extension" это на самом деле очень важная и долгожданная функция для выкаток. Сейчас если сервис использует extension то он не может сам без помощи выкатить схему своей базы, так как для create extension нужен superuser, приходится городить обёртки типа служебных хранимок create_extesion(...) с security definer и т.п. С "trusted extension" это можно будет сделать гораздо проще.
Это упрощает разработку. Не от суперюзера же миграции запускать в стейджинг-среде. На продакшене особо и не надо, да,
Надеюсь, добавят в грядущую версию 20.10 самого лучшего и мейнстримого дистрибутива.
вроде говорили, что последняя версия - 10-ка
Как так, уже ж 11 в бете :)
Мейнстримное лучшим не бывает. В лучших дистрибутивах не нужно гадать успеет ли оно попасть в какую-то там ежегодную циферку - оно туда попадает сразу после выпуска, а до этого попадает в виде бет и rc для тех кому это надо.
10 ка вроде последняя, если вы действительно про "самого лучшего и мейнстримого дистрибутива".10 ка вроде последняя, если вы действительно про "самого лучшего и мейнстримого дистрибутива".
Да я уже понял, что ты пишешь из Бадена.
не "из", а "с" и не "Бадена", а "Бодуна" :)
20.10. ubuntu?
зачем гадать добавят или нет: https://www.postgresql.org/download/linux/ubuntu/
добавляем сами ppa и всё.
Какой ppa? На дворе 2020 и docker образ PostgreSQL ставится в 3 клика.
apt.postgresql.org
А чем сейчас модно визуально в базе ковыряться? А то pgAdmin 4 скатился совсем.
У нас все на DataGrip перешли. Универсальная тула
>DownloadFree 30-day trial :-|
Я тоже год назад пытался фронтендик хоть какой-нибудь накрутить. Но уже забыл, на чём остановился )
EAP-шки бесплатные. https://www.jetbrains.com/datagrip/nextversion/
Формально это даже не бета, а найтли-билд, но по факту все, кроме новых фич, стабильно.Обычно есть либо EAP, либо триал очередного релиза в его роли. Если ставить через snap edge channel, можно вообще ничего не заметить.
Забыл начать писать? :)
Фуфло у вас, а не "тула" - для пальцедрочеров. Большинство операций делается мышой не приходя в сознание.
dbeaver ничего так, поддерживает всё помаленьку. Может не быть фич из узко заточенных инструментов, но минимальный набор посмотреть таблички, сессии, запросы позапускать — есть для большинства БД, которые в дикой природе встречаются.
если он такой умный, почему ни в одних репах его нет? судя по репологи, это арч, ещё пара мелких дистров... и winget
Может быть потому что не нужны репы для того, что распаковывается из архива и работает на любой системе с джавой?
Обязательно нужны. Как минимум, нужно поставить жаву, не удалить её по autoremove, поставить приложение как принято в системе, по правильным путям, с иконками, записями в меню, документацией и манами, а потом обновлять его вместе со всем остальным, а не вспоминать где у тебя по системе распихан протухший софт.
Есть на Flathub: https://flathub.org/apps/details/io.dbeaver.DBeaverCommunity
У dbeaver две редакции, бесплатная и платная, не много людей хотят спонсировать просто так чей-то бизнес, и бесплатно им делать пакеты, а авторам видимо это не интересно плюс так как это java то он просто распаковывается из архива и работает.
https://en.wikipedia.org/wiki/Comparison_of_database_tools
Sequeler. https://github.com/Alecaddd/sequeler#get-it-from-the-element...
Он только для линукса
Ну так и используй линукс!А вообще, в винде WSL завезли, мб и на нём взлетит
TOra
* Support Oracle & MySQL - жидковатенько и не имеет к топику никакого отношения
DBeaver очень хороший вариант.
Визульно скучно: psql 'service=<name>'
все как обычно... psql
https://tableplus.com/
psql. Вы инвалид, зачем вам визуально?
https://github.com/parihaaraka/sqt
>А чем сейчас модно визуально в базе ковыряться?Можно попробовать Kexi из состава Calligra.