- Релиз СУБД PostgreSQL 13, DEF, 19:05 , 24-Сен-20 (1) +26 [^]
- Релиз СУБД PostgreSQL 13, Аноним, 19:08 , 24-Сен-20 (2) +5
- Релиз СУБД PostgreSQL 13, mr.Clin, 22:23 , 24-Сен-20 (27) –4 [V]
- Релиз СУБД PostgreSQL 13, Страшный Аноним, 23:33 , 24-Сен-20 (32) +1
- Релиз СУБД PostgreSQL 13, Аноним, 04:18 , 25-Сен-20 (41)
- Релиз СУБД PostgreSQL 13, 1, 12:15 , 25-Сен-20 (58) –2
- Релиз СУБД PostgreSQL 13, Виталий, 09:20 , 29-Сен-20 (128)
- Релиз СУБД PostgreSQL 13, ptr128, 11:49 , 30-Сен-20 (131)
- Релиз СУБД PostgreSQL 13, Страшный Аноним, 23:38 , 24-Сен-20 (33) –3
- Релиз СУБД PostgreSQL 13, funny.falcon, 03:48 , 25-Сен-20 (40) +1
- Релиз СУБД PostgreSQL 13, Аноним, 04:21 , 25-Сен-20 (43)
- Релиз СУБД PostgreSQL 13, Аноним, 08:02 , 25-Сен-20 (49)
- Релиз СУБД PostgreSQL 13, Аноним, 09:54 , 25-Сен-20 (53)
- Релиз СУБД PostgreSQL 13, лолшто, 17:49 , 25-Сен-20 (71) +1
- Релиз СУБД PostgreSQL 13, лютый жабби__, 12:11 , 26-Сен-20 (86) –1
- Релиз СУБД PostgreSQL 13, YetAnotherOnanym, 19:13 , 24-Сен-20 (3) –5 [V]
- Релиз СУБД PostgreSQL 13, Рева RarogCmex Денис, 19:13 , 24-Сен-20 (4) –1
- Релиз СУБД PostgreSQL 13, Аноним, 19:15 , 24-Сен-20 (6) +5
- Релиз СУБД PostgreSQL 13, Аноним, 19:34 , 24-Сен-20 (10)
- Релиз СУБД PostgreSQL 13, Аноним, 19:43 , 24-Сен-20 (15) +6 [^]
- Релиз СУБД PostgreSQL 13, jOKer, 01:31 , 25-Сен-20 (39)
Это только потому, видимо, что вам _пока_ не требовалось от СУБД умение работать в состоянии расщепления (Partition Tolerance). Как только это произойдет... ну, тогда вы точно запомните случай, когда MongoDB оказалась более эффективной. =)
- Релиз СУБД PostgreSQL 13, Аноним, 07:38 , 25-Сен-20 (47) +4
- Релиз СУБД PostgreSQL 13, jOKer, 18:13 , 25-Сен-20 (72) –1
>[оверквотинг удален]
> 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. Так что на вашем месте я бы ими не козырял. Не стоит.
- Релиз СУБД PostgreSQL 13, Аноним, 04:53 , 26-Сен-20 (78) +1
- Релиз СУБД PostgreSQL 13, jOKer, 08:59 , 26-Сен-20 (82)
> 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. Кроме того, изменения в хеш-индексах после начальной копии не переносятся при потоковой или файловой репликации, так что в последующих запросах они будут давать неправильные ответы. По этим причинам настоятельно рекомендуется не использовать их."
- Релиз СУБД PostgreSQL 13, spectator, 20:15 , 26-Сен-20 (93) +1
- Релиз СУБД PostgreSQL 13, spectator, 20:16 , 26-Сен-20 (94)
- Релиз СУБД PostgreSQL 13, jOKer, 20:56 , 26-Сен-20 (96) –1
> опечатался в первом поле: abbb -> bbb К сожалению, это немножечко не то. Я, в свое время, тоже увидел эту функцию и было обрадовался, и как оказалось - зря. Потому что основную проблему - обновление части документа JSON _на_стороне_сервера_ эта функция не решает. Она _просто_ возвращает видоизмененные данные. Причем, я даже не поручусь, что эти изменения не происходят на стороне клиента. То есть вот эта, трижды клятая в этом треде MongoDB, способна на стороне сервера обновить часть JSON-документа, а PostgreSQL похоже, без доработок-расширений, может обновлять только поле JSONB целиком. Что доставляет проблемы, если ваш документ изрядно большой, допустим в несколько мегабайт. Потому что в этом случае, вам придется весь этот документ забрать по сети на клиент, сделать там его обновление, и потом целиком опять отправить на сервер. А это и дополнительный трафик, и потеря производительности.
- Релиз СУБД PostgreSQL 13, spectator, 21:03 , 26-Сен-20 (97)
- Релиз СУБД PostgreSQL 13, jOKer, 21:16 , 26-Сен-20 (99)
> похоже что вы очень мало писали запросов для постгрес раз не знаете
> как обновить значение
> не стоит спорить не зная основ Еще раз: обновить-то можно. Это как раз не проблема. Вопрос где именно обновлять. Потому что обновлять на стороне клиента - контрпродуктивно... Ладно-ладно, не будем спорить. Но вот когда (и если) вы столкнетесь с ситуацией о которой я говорю (документ в JSONB-поле размером в несколько десятков мегабайт) и начнете просаживать производительность - вспомните тогда меня.
- Релиз СУБД PostgreSQL 13, spectator, 22:17 , 26-Сен-20 (104)
- Релиз СУБД PostgreSQL 13, jOKer, 23:22 , 26-Сен-20 (107)
> вам, возможно, хочется найти оправдание почему вы им не пользуетесьКак раз пользовался. Однако имел при этом проблему: при обновлении объемных документов JSON внутри поля типа JSONB сильно падала производительность микросервиса. После того, как микросервис был переписан под работу с монгой, производительность поднялась на пару порядков. Попутно получил профит при обновлении нескольких значений в документе одновременно. Хотя вот при работе с небольшими документами проблем у PostgreSQL мной замечено не было. Это и заставило меня предположить что операция обновления данных внутри поля типа JSONB полностью или частично выполняется на стороне клиента.
- Релиз СУБД PostgreSQL 13, Аноним, 20:34 , 26-Сен-20 (95) –3
- Релиз СУБД PostgreSQL 13, jOKer, 21:10 , 26-Сен-20 (98)
>[оверквотинг удален]
>
>
> jsonb_set
> ---------------------------------------------------------------
> {"aaa": 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 100500}}]}
> Update уж сами допишете.
>> операции с индексом типа "hash" не попадают в WAL
> Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
> Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно
> пишется. То ли с 9-й версии, то ли с 10-й.А если твой документ мегабайт этак ~дцать, так и будешь тягать его по сети туда-сюда, а? Там где монга _на стороне сервера_ обновит документ из коллекции передавая по сети только определение операции, ты будешь тягать документ _целиком_. Что ты там писал про индусов постом выше? Так вот, с таким подходом, ты именно этот индус и есть.
- Релиз СУБД PostgreSQL 13, Аноним, 22:01 , 26-Сен-20 (101) +1
- Релиз СУБД PostgreSQL 13, jOKer, 22:58 , 26-Сен-20 (105) –3
> Где тут таскание по сети? jsonb_set делается на стороне postgresql сервера.
>jsonb_set делается на стороне postgresql сервераНе уверен. Факт, что PostgreSQL при всех раскладах будет обновлять поле только целиком.
Следовательно ему нужно взять содержимое, обновить его, и положить обратно. Это само по себе затратно. Но этого мало, потому что не известно где именно происходит само обновление. Я думаю все же, что на клиенте. Возможно только частично. И я думаю так же, что все это время сервер держит блокировку, и вот это-то и может объяснить просадку быстродействия, которая начинает наблюдаться, при обновлении полей с объемными JSON-документами внутри.... Блин, но вы таки заронили зерно сомнения, да. Буду копать глубже. Сейчас спорить не буду, - фактов ни "за", ни "против" у меня нет. Возможно отпишусь позже, когда пройдусь сканером трафика, что бы посмотреть что именно отправляется на клиент и обратно.
- Релиз СУБД PostgreSQL 13, Аноним, 22:03 , 26-Сен-20 (102)
- Релиз СУБД PostgreSQL 13, jOKer, 23:59 , 26-Сен-20 (108)
> А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в
> update переписать не можете.Очень смешно. Шутник. > И кто тут индус? Ладно, за "индуса" извините, погорячился.
- Релиз СУБД PostgreSQL 13, edo, 05:49 , 28-Сен-20 (120)
- Релиз СУБД PostgreSQL 13, jOKer, 21:50 , 26-Сен-20 (100) –1
>> операции с индексом типа "hash" не попадают в WAL
> Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
> Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно
> пишется. То ли с 9-й версии, то ли с 10-й.Да, тут я, похоже, не прав. Сейчас сличил версии официальных документаций: начиная с 10-ой версии, они свое грозное предупреждение, которое я процитировал в переводе, убрали. Так что вероятно эта проблема уже решена. Что же... +1 PostgreSQL в таком случае. =) Я в последний раз столкнулся с этой траблой на 9.6 Там она еще была.
- Релиз СУБД PostgreSQL 13, phil, 22:16 , 28-Сен-20 (127)
- Релиз СУБД PostgreSQL 13, jOKer, 20:09 , 30-Сен-20 (132)
Увеличивать эту константу имеет смысл только есть у вас много ОЗУ, потому что она и выбрана-то была, с тем расчетом, что бы документ в ОЗУ поместился с гарантией.Куда проще (и это официально рекомендованный вариант) использовать для хранения GridFS. В этом случае, документ бьется на чанки, что конечно снижает общую производительность, но не так уж и сильно. Но вот документ при этом, может достигать значительно больших размеров.
- Релиз СУБД PostgreSQL 13, лютый жабби__, 12:14 , 26-Сен-20 (87)
- Релиз СУБД PostgreSQL 13, AleksK, 21:23 , 24-Сен-20 (25)
- Релиз СУБД PostgreSQL 13, ВХОД, 22:33 , 24-Сен-20 (28)
- Релиз СУБД PostgreSQL 13, Страшный Аноним, 23:30 , 24-Сен-20 (31)
- Релиз СУБД PostgreSQL 13, Аноним, 00:54 , 25-Сен-20 (35)
- Релиз СУБД PostgreSQL 13, Sw00p aka Jerom, 01:00 , 25-Сен-20 (36)
- Релиз СУБД PostgreSQL 13, AleksK, 08:37 , 25-Сен-20 (52)
- Релиз СУБД PostgreSQL 13, mmrnmhrm, 23:31 , 27-Сен-20 (115)
- Релиз СУБД PostgreSQL 13, InuYasha, 13:26 , 25-Сен-20 (62) –1
- Релиз СУБД PostgreSQL 13, Catwoolfii, 19:36 , 24-Сен-20 (11) –6 [V]
- Релиз СУБД PostgreSQL 13, Аноним, 19:51 , 24-Сен-20 (17)
- Релиз СУБД PostgreSQL 13, DEF, 20:03 , 24-Сен-20 (19)
- Релиз СУБД PostgreSQL 13, Аноним, 20:20 , 24-Сен-20 (20) +1
- Релиз СУБД PostgreSQL 13, ВХОД, 22:38 , 24-Сен-20 (29) +3
- Релиз СУБД PostgreSQL 13, a, 23:10 , 24-Сен-20 (30) –3
- Релиз СУБД PostgreSQL 13, Аноним, 13:30 , 25-Сен-20 (63) +2
- Релиз СУБД PostgreSQL 13, Аноним, 09:23 , 26-Сен-20 (83) +1
- Релиз СУБД PostgreSQL 13, tim2k, 11:17 , 25-Сен-20 (55) +1
- Релиз СУБД PostgreSQL 13, Аноним, 11:54 , 25-Сен-20 (56) +1
- Релиз СУБД PostgreSQL 13, Аноним, 12:18 , 25-Сен-20 (59) +8 [^]
- Релиз СУБД PostgreSQL 13, Аноним, 12:50 , 25-Сен-20 (60)
- Релиз СУБД PostgreSQL 13, Аноним, 14:08 , 25-Сен-20 (65)
- Релиз СУБД PostgreSQL 13, SysA, 14:13 , 25-Сен-20 (66) –1
- Релиз СУБД PostgreSQL 13, Avator, 17:09 , 25-Сен-20 (70)
- Релиз СУБД PostgreSQL 13, worldmind, 18:45 , 25-Сен-20 (73) +1
- Релиз СУБД PostgreSQL 13, rshadow, 20:26 , 25-Сен-20 (75) +1
- Релиз СУБД PostgreSQL 13, ivanpetrov, 00:19 , 28-Сен-20 (117)
- Релиз СУБД PostgreSQL 13, Аноним, 02:22 , 28-Сен-20 (119)
- Релиз СУБД PostgreSQL 13, andrey, 17:30 , 29-Сен-20 (129)
- Релиз СУБД PostgreSQL 13, Аноним, 18:10 , 29-Сен-20 (130)
|
Версия для распечатки
Релиз СУБД PostgreSQL 13,
opennews, 24-Сен-20, 19:05 [смотреть все]
