Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз СУБД PostgreSQL 13"	+/–
Сообщение от opennews (?), 24-Сен-20, 19:05
После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 13.  Обновления для новой ветки будут выходить в течение пяти лет до ноября 2025 года... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53774
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от DEF (?), 24-Сен-20, 19:05	+26 +/–
Замечательная БД. Лучшая в мире, имхо.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #27, #32, #33, #71, #86

2. Сообщение от Аноним (2), 24-Сен-20, 19:08	+5 +/–
Постгря объективно лучшая, так что имхо тут лишнее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7, #12

3. Сообщение от YetAnotherOnanym (ok), 24-Сен-20, 19:13	–5 +/–
> Реализована концепция заслуживающих доверия дополнений Ждём появления магазина дополнений, которые можно ставить в один клик. А то несовременный он какой-то, этот Постгрес.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #13

4. Сообщение от Рева RarogCmex Денис (?), 24-Сен-20, 19:13	–1 +/–
Неплохая бд под свои цели (тяжелые приложения под реляционрую базу данных). Понятно, что в ряде случаев тот же sqlite, mongodb или redis -- на порядки эффективнее. Выбирать нужно по техзаданию базу данных, и не париться ;)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #10, #25, #62

5. Сообщение от Рева RarogCmex Денис (?), 24-Сен-20, 19:13	+/–
Куда же без монетизации и монетизации на монетизацию?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от Аноним (6), 24-Сен-20, 19:15	+5 +/–
sqlite на порядки эффективнее - это интересная идея. Удобнее и компактнее - да, но вот эффективнее...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #8, #9

7. Сообщение от Аноним (7), 24-Сен-20, 19:19	+6 +/–
Ну, это вы за своё имхо так говорите!  :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

8. Сообщение от Аноним (8), 24-Сен-20, 19:31	+4 +/–
В РЯДЕ СЛУЧАЕВ эффективнее внимательнее надо с областью определения утверждений
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #14

9. Сообщение от Аноним (9), 24-Сен-20, 19:31	+6 +/–
Для записной книжки в телефоне - эффективнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #85

10. Сообщение от Аноним (9), 24-Сен-20, 19:34	+/–
Кстати, не припомню ни одного случая, когда монга была бы именно эффективнее. Проще в разработке и поддержке - да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #15, #39, #87

11. Сообщение от Catwoolfii (ok), 24-Сен-20, 19:36	–6 +/–
Вот storage engines так и не завезли...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #50

12. Сообщение от Аноним (12), 24-Сен-20, 19:41	–7 +/–
Постгрес, там «с» в конце.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #18

13. Сообщение от Аноним (12), 24-Сен-20, 19:43	+2 +/–
https://pgxn.org/about/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #37

14. Сообщение от Sw00p aka Jerom (?), 24-Сен-20, 19:43	+/–
даже не В РЯДЕ СЛУЧАЕВ, а в В НЕКОТОРЫХ СЛУЧАЯХ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #16

15. Сообщение от Аноним (15), 24-Сен-20, 19:43	+6 +/–
В основном в разработке чужого бюджета
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от Аноним (8), 24-Сен-20, 19:49	+3 +/–
В исходном утверждении стоит именно в ряде случаев. Не понимаю, что за мода выкидывать/заменять часть утверждений и затем горячо критиковать получившееся. Это же типичный демагогический прием.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #34

17. Сообщение от Аноним (17), 24-Сен-20, 19:51	+/–
Кроме "trusted extension" всё выглядит как нужные и полезные кому-то вещи. А вот эти белые списки дополнений как-то выглядят небезопасно. Если это такие хорошие и полезные дополнения, то и включите их просто в конфиге по-умолчанию. Кому надо те отключат. Зато нерутовым юзерам не надо будет иметь возможность их включать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #51

18. Сообщение от Аноним (18), 24-Сен-20, 19:57	+7 +/–
«с» не в конце, а в начале SQL
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #21, #22, #23

19. Сообщение от DEF (?), 24-Сен-20, 20:03	+/–
Надеюсь, добавят в грядущую версию 20.10 самого лучшего и мейнстримого дистрибутива.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #29, #30, #63, #83

20. Сообщение от Аноним (20), 24-Сен-20, 20:20	+1 +/–
вроде говорили, что последняя версия - 10-ка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #92

21. Сообщение от Аноним (21), 24-Сен-20, 20:21	–1 +/–
А в слове "прогресс" тоже в начале? Или это такой троллинг? Вообще надо секту "постгрЭ" законожательно запретить как сделали с АУЕ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26

22. Сообщение от Аноним (12), 24-Сен-20, 20:46	+13 +/–
Нет, https://ru.wikipedia.org/wiki/PostgreSQL Слово postgres образовано от "Post Ingres" и изначально никакого SQL он не поддерживал. После реализации SQL авторы решили что название postgres95 не очень и что будет прикольно написать "PostgresSQL", а ещё круче — убрав дубль S, "PostgreSQL" и произносить «Пост-Грэс-Кью-Эл», о чём теперь жалеют и считают что это было ошибкой, потому что при увеличении сообщества приходится всё время объяснять новичкам правильное название базы :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

23. Сообщение от Аноним (23), 24-Сен-20, 20:57	+2 +/–
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).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

24. Сообщение от Аноним (12), 24-Сен-20, 21:02	+/–
> Список подобных дополнений изначально предопределён и может быть расширен суперпользователем. Тут просто не совсем понятно написано, никаких явных списков там нет, trusted — это просто _флаг в самом файле с описанием extension_. > включите их просто в конфиге по-умолчанию Администратор всегда при установке может отредактировать template1 базу сам сделав всё что ему нужно доступным по умолчанию. Если это сделают авторы postgres то потеряется возможность сделать пустую базу, в ней всегда будут какие-то объекты из предложенных вами расширений, потеряется гибкость. "trusted extension" это на самом деле очень важная и долгожданная функция для выкаток. Сейчас если сервис использует extension то он не может сам без помощи выкатить схему своей базы, так как для create extension нужен superuser, приходится городить обёртки типа служебных хранимок create_extesion(...) с security definer и т.п. С "trusted extension" это можно будет сделать гораздо проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

25. Сообщение от AleksK (ok), 24-Сен-20, 21:23	+/–
sqlite удобнее для разработки, но никак не эффективнее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #28, #31

26. Сообщение от Аноним (18), 24-Сен-20, 21:28	+1 +/–
> А в слове "прогресс" тоже в начале? Если ты заметил, в "прогресс" нет суффикса SQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

27. Сообщение от mr.Clin (?), 24-Сен-20, 22:23	–4 +/–
Ага, настолько классная что Uber с неё свинтил на MySQL + свой напилиник по понятным причинам...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #42, #48

28. Сообщение от ВХОД (?), 24-Сен-20, 22:33	+/–
Не сказал бы что он удобнее учитывая что ничего не умеет толком и инструментов под него нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

29. Сообщение от ВХОД (?), 24-Сен-20, 22:38	+3 +/–
Мейнстримное лучшим не бывает. В лучших дистрибутивах не нужно гадать успеет ли оно попасть в какую-то там ежегодную циферку - оно туда попадает сразу после выпуска, а до этого попадает в виде бет и rc для тех кому это надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

30. Сообщение от a (??), 24-Сен-20, 23:10	–3 +/–
10 ка вроде последняя, если вы действительно про "самого лучшего и мейнстримого дистрибутива".10 ка вроде последняя, если вы действительно про "самого лучшего и мейнстримого дистрибутива".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #38

31. Сообщение от Страшный Аноним (?), 24-Сен-20, 23:30	+/–
У вот таких эффективных пацанчиков, вроде тебя, на мобильниках тоже стоит эффективный PostgreSQL? Если да, то обращайтесь - у меня друг очень хороший психиатр.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #35, #36, #52, #115

32. Сообщение от Страшный Аноним (?), 24-Сен-20, 23:33	+1 +/–
Куда там Oracle, Ms SQL Server и IBM DB2, да? Это просто мальчики для биться по сравнению с вакуумным Postgre? Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #41, #58, #128, #131

33. Сообщение от Страшный Аноним (?), 24-Сен-20, 23:38	–3 +/–
Кстати, как там в Postgre с партиционированием, завезли полноценное или еще на 5 лет отставили? Для тех, кто тогда ходил под стол, сообщаю, что партиционированию в Oracle больше 20 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #40, #43, #49, #53

34. Сообщение от Sw00p aka Jerom (?), 25-Сен-20, 00:49	–1 +/–
> Не понимаю, что за мода выкидывать/заменять часть утверждений и затем горячо критиковать > получившееся. Это же типичный демагогический прием. И ну и как тут не ответить? Мой комент был всего лишь поправкой, и с исходным коментом я согласен, что СУБД нужно выбирать исходя из необходимых и достаточных требований (по ТЗ). А далее немного демагогии (можете пропустить) .... Давайте посмотрим на одно из определений слова Ряд (из вики): """ Ряд — некоторое, немалое количество, например «ряд стран». """ Тут пояснения нужны, что словом Ряд можно заменить слово Некоторое? Эту моду придумал не я.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

35. Сообщение от Аноним (35), 25-Сен-20, 00:54	+/–
Аналогов то SQLite по сути вообще нет на мобильниках
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

36. Сообщение от Sw00p aka Jerom (?), 25-Сен-20, 01:00	+/–
> У вот таких эффективных пацанчиков у "сверх эффективных" даже оракля встречается :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

37. Сообщение от YetAnotherOnanym (ok), 25-Сен-20, 01:07	+/–
> https://pgxn.org/about/ О, круто! А дыры, дыры-то есть? А то ж дополнение без дыр - это какое-то неполноценное дополнение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #44

38. Сообщение от YetAnotherOnanym (ok), 25-Сен-20, 01:10	+/–
Да я уже понял, что ты пишешь из Бадена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #54

39. Сообщение от jOKer (ok), 25-Сен-20, 01:31	+/–
Это только потому, видимо, что вам _пока_ не требовалось от СУБД умение работать в состоянии расщепления (Partition Tolerance). Как только это произойдет... ну, тогда вы точно запомните случай, когда MongoDB оказалась более эффективной. =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #47

40. Сообщение от funny.falcon (?), 25-Сен-20, 03:48	+1 +/–
На ручном приводе я ещё в 2003 партицирование делал пользуясь наследованием, которое вроде ещё с 80х в постгресе. Но, конечно, это было не так удобно, как полностью поддержанное самой базой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

41. Сообщение от Аноним (42), 25-Сен-20, 04:18	+/–
Правильно писать Postgres
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #46, #57, #69

42. Сообщение от Аноним (42), 25-Сен-20, 04:20	+1 +/–
Свой напильник можно было и в постгресе сделать, это чисто политическое решение, о миграции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

43. Сообщение от Аноним (42), 25-Сен-20, 04:21	+/–
В postgres, да, завезли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

44. Сообщение от Аноним (42), 25-Сен-20, 04:22	+/–
Как напишешь — так и будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

45. Сообщение от funny.falcon (?), 25-Сен-20, 06:32	+1 +/–
Не совсем. Если говорить чуть более абстрактно, то FDW умеет очень много. Может не полноценная замена storage engines, но зато подходит и для других задач. Если говорить конкретно, то ЕЩЁ не завезли. Они работают над этим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

46. Сообщение от Pers (??), 25-Сен-20, 07:19	+13 +/–
Лучший ответ на заданный вопрос )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

47. Сообщение от Аноним (48), 25-Сен-20, 07:38	+4 +/–
Монга первая в мире СУБД с 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) справится и на одном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #72

48. Сообщение от Аноним (48), 25-Сен-20, 07:59	+9 +/–
Если бы Uber провёл то самое исследование производительности на этапе проектирования структуры базы, а не когда все уперлось в обновление индексов, можно было бы и никуда не валить, а спроектировать базу с применением головного мозга. У них там была таблица с индексом почти на каждое поле, и она обновлялась по сто раз в секунду. Это им ещё повезло, что внутреннее устройство innodb подошло под их кейс, и что они не обновляли primary key (вот тут бы innodb вообще обвалился - там pk=oid грубо говоря). Но эта проблема ещё валидная (и с тех пор в ее в pg не то, чтобы целиком решили, но существенно смягчили), все остальное вообще из разряда «не осилили».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #61

49. Сообщение от Аноним (48), 25-Сен-20, 08:02	+/–
Давно уже есть. С десятой версии вроде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

50. Сообщение от Аноним (48), 25-Сен-20, 08:05	+1 +/–
Это палка о двух концах. Любая абстракция усложняет оптимизацию. А костылями и подпорками, как в MySQL, в постгресе не прокатит, там другая культура разработки (точнее, она там присутствует в отличие от). Тут надо и на елку влезть, и не поцарапаться, это непростая задача. Но исследования ведутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

51. Сообщение от Аноним (48), 25-Сен-20, 08:08	+/–
Это упрощает разработку. Не от суперюзера же миграции запускать в стейджинг-среде. На продакшене особо и не надо, да,
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

52. Сообщение от AleksK (ok), 25-Сен-20, 08:37	+/–
Что такой агрессивный? Тебя web-разработчики били что ли? А для чего тебе СУБД на смартфоне? Для хранения локальных данных и настроек? Как только к sqlite подцепляется больше одного клиента вся его "эффективность" улетучивается. Поэтому он подходит для прототипирования при разработке, и хранения локальных данных одного приложения, и то в этом случае зачастую подойдет обычное хранилище ключ-значение. Были ещё варианты его применения, но это была совсем экзотика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #74

53. Сообщение от Аноним (53), 25-Сен-20, 09:54	+/–
Это только в энтерпрайзной версии, которая многие миллионы стоит, которую только супер корпорации позволить себе могут. В MSSQL больше фич за 300к.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

54. Сообщение от garrick (?), 25-Сен-20, 10:01	+2 +/–
не "из", а "с" и не "Бадена", а "Бодуна" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

55. Сообщение от tim2k (ok), 25-Сен-20, 11:17	+1 +/–
А чем сейчас модно визуально в базе ковыряться? А то pgAdmin 4 скатился совсем.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #56, #59, #60, #65, #66, #70, #73, #75, #117, #119, #129, #130

56. Сообщение от Аноним (56), 25-Сен-20, 11:54	+1 +/–
У нас все на DataGrip перешли. Универсальная тула
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #64, #88

57. Сообщение от Аноним (57), 25-Сен-20, 12:15	–1 +/–
Да там и с русским проблема, не то что с названиями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

58. Сообщение от 1 (??), 25-Сен-20, 12:15	–2 +/–
Чтоб продавать постгре вместо оракла. Но на больших БД - поддержка постгри дороже оракловской.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #67

59. Сообщение от Аноним (57), 25-Сен-20, 12:18	+8 +/–
dbeaver ничего так, поддерживает всё помаленьку. Может не быть фич из узко заточенных инструментов, но минимальный набор посмотреть таблички, сессии, запросы позапускать — есть для большинства БД, которые в дикой природе встречаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #81

60. Сообщение от Аноним (60), 25-Сен-20, 12:50	+/–
https://en.wikipedia.org/wiki/Comparison_of_database_tools
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

61. Сообщение от mr.Clin (?), 25-Сен-20, 13:12	+/–
Там не только проблема со вторичными индексами была, с VACUUM проблема более-менее тоже актуальная на больших объёмах данных при постоянной перезаписи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #77, #79

62. Сообщение от InuYasha (??), 25-Сен-20, 13:26	–1 +/–
в моей практике mongodb был менее стабилен под большой нагрузкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #116

63. Сообщение от Аноним (63), 25-Сен-20, 13:30	+2 +/–
20.10. ubuntu? зачем гадать добавят или нет: https://www.postgresql.org/download/linux/ubuntu/ добавляем сами ppa и всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #122

64. Сообщение от InuYasha (??), 25-Сен-20, 13:31	–1 +/–
>Download Free 30-day trial :-| Я тоже год назад пытался фронтендик хоть какой-нибудь накрутить. Но уже забыл, на чём остановился )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #68, #91

65. Сообщение от Аноним (65), 25-Сен-20, 14:08	+/–
Sequeler. https://github.com/Alecaddd/sequeler#get-it-from-the-element...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #89

66. Сообщение от SysA (?), 25-Сен-20, 14:13	–1 +/–
TOra
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #90

67. Сообщение от Аноним (12), 25-Сен-20, 14:46	+/–
Очевидно что вы не разбираетесь в теме раз даже не знаете как база правильно называется :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

68. Сообщение от Аноним (9), 25-Сен-20, 16:21	–1 +/–
EAP-шки бесплатные. https://www.jetbrains.com/datagrip/nextversion/ Формально это даже не бета, а найтли-билд, но по факту все, кроме новых фич, стабильно. Обычно есть либо EAP, либо триал очередного релиза в его роли. Если ставить через snap edge channel, можно вообще ничего не заметить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

69. Сообщение от InuYasha (??), 25-Сен-20, 17:01	–1 +/–
Правильно - рисовать слоника )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #76

70. Сообщение от Avator (ok), 25-Сен-20, 17:09	+/–
DBeaver очень хороший вариант.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

71. Сообщение от лолшто (?), 25-Сен-20, 17:49	+1 +/–
Лучшая в мире БД для лучшего в мире юзкейса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

72. Сообщение от jOKer (ok), 25-Сен-20, 18:13	–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. Так что на вашем месте я бы ими не козырял. Не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #78, #127

73. Сообщение от worldmind (?), 25-Сен-20, 18:45	+1 +/–
Визульно скучно: psql 'service=<name>'
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

74. Сообщение от Аноним (74), 25-Сен-20, 20:11	–1 +/–
А у тебя к адресной книге на телефоне прямо несколько клиентов подключаются. Глупости не говори. Оставим в покое телефоны, посмотри какую какашку с akonadi сделали. Да, sqlite эфективнее во многих местах, но не в вебне откуда ты пришёл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

75. Сообщение от rshadow (ok), 25-Сен-20, 20:26	+1 +/–
все как обычно... psql
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

76. Сообщение от Аноним (57), 25-Сен-20, 20:47	+/–
А при чём здесь РНР?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #126

77. Сообщение от zzz (??), 26-Сен-20, 04:45	+/–
Проблема там была только с мозгами и откатами. Устроить миграцию MySQL - PostreSQL - MySQL без нагрузочного тестирования, на шару - это надо быть или идиотом, или умным распильщиком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

78. Сообщение от Аноним (48), 26-Сен-20, 04:53	+1 +/–
О, вот и фанбои подтянулись. >  обновить _отдельный атрибут_ (!) https://www.postgresql.org/docs/13/functions-json.html Все можно, читай внимательно. >  "банальные хэши" сто лет в обед в PostgreSQL считаются индексом не рекомендуемым к применению. Внезапно. А все потому что не проходят в WAL. Чего?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #82

79. Сообщение от Аноним (48), 26-Сен-20, 05:01	+/–
Про вакуум в постгресе знают вроде вообще все, даже те, кто запросов сложнее select * from table в свой жизни ни разу не писал. Кроме разработчиков Убера, видимо, для которых это оказалось новостью когда все прилегло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #80

80. Сообщение от n242name (?), 26-Сен-20, 06:21	–4 +/–
Как может быть лучше субд у которой это говновакуум вообще существует? А дебильные имена объектов в UPPERCASE? НаверноеЕстьРазница? ИЛИВСЕТАКИНИКАКОЙРАЗНИЦЫНЕТ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #109

81. Сообщение от бедный буратино (ok), 26-Сен-20, 07:03	–4 +/–
если он такой умный, почему ни в одних репах его нет? судя по репологи, это арч, ещё пара мелких дистров... и winget
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #84, #103, #110

82. Сообщение от jOKer (ok), 26-Сен-20, 08:59	+/–
> 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. Кроме того, изменения в хеш-индексах после начальной копии не переносятся при потоковой или файловой репликации, так что в последующих запросах они будут давать неправильные ответы. По этим причинам настоятельно рекомендуется не использовать их."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #93, #95

83. Сообщение от Аноним (83), 26-Сен-20, 09:23	+1 +/–
apt.postgresql.org
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

84. Сообщение от Аноним (84), 26-Сен-20, 10:47	+/–
Может быть потому что не нужны репы для того, что распаковывается из архива и работает на любой системе с джавой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #118

85. Сообщение от x3who (?), 26-Сен-20, 11:31	+/–
> Для записной книжки в телефоне - эффективнее. Таких инсталляций на порядки больше, чем корпоративных БД. Так что правильно говорить о незначительном количестве юзкейсов, в которых sqlite всё ещё уступает Постгресу и Ораклу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

86. Сообщение от лютый жабби__ (?), 26-Сен-20, 12:11	–1 +/–
>Лучшая в мире, имхо. JSON там считай что нет. Соответственно, лучшая средневековая СУБД. В Монге, кстати, уже давно и транзакции завезли (хотя они по прежнему не нужны в 98% случаев).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #106

87. Сообщение от лютый жабби__ (?), 26-Сен-20, 12:14	+/–
>когда монга была бы именно эффективнее. Проще в разработке и поддержке - да. учитывая, что у большинства продуктов процесс ДОработки бесконечный, монга уместнее почти всегда. увы и ах...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

88. Сообщение от Gogi (??), 26-Сен-20, 14:06	+/–
Фуфло у вас, а не "тула" - для пальцедрочеров. Большинство операций делается мышой не приходя в сознание.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

89. Сообщение от Gogi (??), 26-Сен-20, 14:06	–1 +/–
Он только для линукса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #123

90. Сообщение от Gogi (??), 26-Сен-20, 14:08	+/–
* Support Oracle & MySQL - жидковатенько и не имеет к топику никакого отношения
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

91. Сообщение от Gogi (??), 26-Сен-20, 14:09	+/–
Забыл начать писать? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

92. Сообщение от Аноним (92), 26-Сен-20, 14:34	+/–
Как так, уже ж 11 в бете :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

93. Сообщение от spectator (??), 26-Сен-20, 20:15	+1 +/–
column1 = jsonb_set(column1, '{abbb,0,rrrr,fdrt}','123', true)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #94

94. Сообщение от spectator (??), 26-Сен-20, 20:16	+/–
опечатался в первом поле: abbb -> bbb
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #96

95. Сообщение от Аноним (9), 26-Сен-20, 20:34	–3 +/–
> попробуйте составить запрос Попробуйте все же научиться читать. Один раз покажу, дальше сами. =# 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-й.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #98, #100

96. Сообщение от jOKer (ok), 26-Сен-20, 20:56	–1 +/–
> опечатался в первом поле: abbb -> bbb К сожалению, это немножечко не то. Я, в свое время, тоже увидел эту функцию и было обрадовался, и как оказалось - зря. Потому что основную проблему - обновление части документа JSON _на_стороне_сервера_ эта функция не решает. Она _просто_ возвращает видоизмененные данные. Причем, я даже не поручусь, что эти изменения не происходят на стороне клиента. То есть вот эта, трижды клятая в этом треде MongoDB, способна на стороне сервера обновить часть JSON-документа, а PostgreSQL похоже, без доработок-расширений, может обновлять только поле JSONB целиком. Что доставляет проблемы, если ваш документ изрядно большой, допустим в несколько мегабайт. Потому что в этом случае, вам придется весь этот документ забрать по сети на клиент, сделать там его обновление, и потом целиком опять отправить на сервер. А это и дополнительный трафик, и потеря производительности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #97

97. Сообщение от spectator (??), 26-Сен-20, 21:03	+/–
похоже что вы очень мало писали запросов для постгрес раз не знаете как обновить значение не стоит спорить не зная основ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #99

98. Сообщение от jOKer (ok), 26-Сен-20, 21:10	+/–
>[оверквотинг удален] >             >             >     jsonb_set > --------------------------------------------------------------- >  {"aaa": 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 100500}}]} > Update уж сами допишете. >> операции с индексом типа "hash" не попадают в WAL > Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним. > Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно > пишется. То ли с 9-й версии, то ли с 10-й. А если твой документ мегабайт этак ~дцать, так и будешь тягать его по сети туда-сюда, а? Там где монга _на стороне сервера_ обновит документ из коллекции передавая по сети только определение операции, ты будешь тягать документ _целиком_. Что ты там писал про индусов постом выше? Так вот, с таким подходом, ты именно этот индус и есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #101, #102, #120

99. Сообщение от jOKer (ok), 26-Сен-20, 21:16	+/–
> похоже что вы очень мало писали запросов для постгрес раз не знаете > как обновить значение > не стоит спорить не зная основ Еще раз: обновить-то можно. Это как раз не проблема. Вопрос где именно обновлять. Потому что обновлять на стороне клиента - контрпродуктивно... Ладно-ладно, не будем спорить. Но вот когда (и если) вы столкнетесь с ситуацией о которой я говорю (документ в JSONB-поле размером в несколько десятков мегабайт) и начнете просаживать производительность - вспомните тогда меня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #104

100. Сообщение от jOKer (ok), 26-Сен-20, 21:50	–1 +/–
>> операции с индексом типа "hash" не попадают в WAL > Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним. > Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно > пишется. То ли с 9-й версии, то ли с 10-й. Да, тут я, похоже, не прав. Сейчас сличил версии официальных документаций: начиная с 10-ой версии, они свое грозное предупреждение, которое я процитировал в переводе, убрали. Так что вероятно эта проблема уже решена. Что же... +1 PostgreSQL в таком случае. =) Я в последний раз столкнулся с этой траблой на 9.6 Там она еще была.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

101. Сообщение от Аноним (9), 26-Сен-20, 22:01	+1 +/–
Где тут таскание по сети? jsonb_set делается на стороне postgresql сервера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #105

102. Сообщение от Аноним (9), 26-Сен-20, 22:03	+/–
А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в update переписать не можете. update tablename set fieldname = jsonb_set(fieldname, $1, $2), где $1 = path, $2 = new value. И кто тут индус?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #108

103. Сообщение от Аноним (103), 26-Сен-20, 22:04	+1 +/–
Есть на Flathub: https://flathub.org/apps/details/io.dbeaver.DBeaverCommunity
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

104. Сообщение от spectator (??), 26-Сен-20, 22:17	+/–
Подумайте зачем сделали целую функцию jsonb_set если мы можем спокойно оперировать json-ом на стороне клиента? Ладно, люди которые хотели узнать можно ли обновлять jsonb в postgres уже наверняка разобрались, а вам, возможно, хочется найти оправдание почему вы им не пользуетесь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #107

105. Сообщение от jOKer (ok), 26-Сен-20, 22:58	–3 +/–
> Где тут таскание по сети? jsonb_set делается на стороне postgresql сервера. >jsonb_set делается на стороне postgresql сервера Не уверен. Факт, что PostgreSQL при всех раскладах будет обновлять поле только целиком. Следовательно ему нужно взять содержимое, обновить его, и положить обратно. Это само по себе затратно. Но этого мало, потому что не известно где именно происходит само обновление. Я думаю все же, что на клиенте. Возможно только частично. И я думаю так же, что все это время сервер держит блокировку, и вот это-то и может объяснить просадку быстродействия, которая начинает наблюдаться, при обновлении полей с объемными JSON-документами внутри.... Блин, но вы таки заронили зерно сомнения, да. Буду копать глубже. Сейчас спорить не буду, - фактов ни "за", ни "против" у меня нет. Возможно отпишусь позже, когда пройдусь сканером трафика, что бы посмотреть что именно отправляется на клиент и обратно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #112

106. Сообщение от Cykooz (ok), 26-Сен-20, 23:09	+/–
В монге так реализовали транзакции, что и оставшиеся 2% не выйдет использовать. Они работают только в реплик-сетах, и при этом не работают на шардированных коллекциях (обещали позднее сделать). А без шардирования монга полезна в редких случаях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #113

107. Сообщение от jOKer (ok), 26-Сен-20, 23:22	+/–
> вам, возможно, хочется найти оправдание почему вы им не пользуетесь Как раз пользовался. Однако имел при этом проблему: при обновлении объемных документов JSON внутри поля типа JSONB сильно падала производительность микросервиса. После того, как микросервис был переписан под работу с монгой, производительность поднялась на пару порядков. Попутно получил профит при обновлении нескольких значений в документе одновременно. Хотя вот при работе с небольшими документами проблем у PostgreSQL мной замечено не было. Это и заставило меня предположить что операция обновления данных внутри поля типа JSONB полностью или частично выполняется на стороне клиента.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

108. Сообщение от jOKer (ok), 26-Сен-20, 23:59	+/–
> А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в > update переписать не можете. Очень смешно. Шутник. > И кто тут индус? Ладно, за "индуса" извините, погорячился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

109. Сообщение от Аноним (42), 27-Сен-20, 00:21	–1 +/–
В postgres регистронезависимые имена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #111

110. Сообщение от Аноним (42), 27-Сен-20, 00:30	+/–
У dbeaver две редакции, бесплатная и платная, не много людей хотят спонсировать просто так чей-то бизнес, и бесплатно им делать пакеты, а авторам видимо это не интересно плюс так как это java то он просто распаковывается из архива и работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

111. Сообщение от n242name (?), 27-Сен-20, 01:41	–1 +/–
> В postgres регистронезависимые имена. но регистр он не запоминает.. в отличии от MySQL можно смело забыть про PascalCase
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

112. Сообщение от Аноним (9), 27-Сен-20, 06:22	+/–
На сервер отправляется sql-запрос, клиенту приходит результат его выполнения. jsonb_set это постгресовская функция, выполняемая на сервере. Никаких промежуточных штук типа коллбэков в протоколе нет, я когда-то писал свою реализацию постгрес-клиента с нуля (будете смеяться, для php! Но с асинхронкой - еще до того, как появился ReactPHP и подобное, был только pecl/libevent), можете мне поверить на слово :-) Другое дело, что со стороны сервера в mongodb действительно обновление части документа может быть более эффективным - когда постгресу надо распарсить весь jsonb, выполнить jsonb_set и потом сохранить все целиком, в монге могут быть оптимизации. Но я не уверен, что они там есть :-) Да и в целом производительность поиска меня волнует намного больше, чем производительность обновления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

113. Сообщение от лютый жабби__ (?), 27-Сен-20, 11:44	+/–
>Они работают только в реплик-сетах Я вообще ХЗ как может быть невасян СУБД без реплик... учитывая время разворачивания бэкапа на несколько ТБ. Любое железо смертно. А про шардирование, вот прямо никак без него? У меня базы по 1-3ТБ нормально ворочаются без него... Так что "оставшиеся 2% не выйдет использовать" это false.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #114

114. Сообщение от Cykooz (ok), 27-Сен-20, 13:24	+/–
> Я вообще ХЗ как может быть невасян СУБД без реплик... учитывая время > разворачивания бэкапа на несколько ТБ. Любое железо смертно. Если придираться к словам, то репликация - это не то же самое что бекап, и не заменяет его. Необходимость поднимать реплик-сет, только ради транзакций, доставляет немного хлопот в процессе разработки. С классическими RDB достаточно запустить их в минимальной конфигурации и весь функционал будет работать. > А про шардирование, вот прямо никак без него? У меня базы по > 1-3ТБ нормально ворочаются без него... Думаю и другие базы данных вполне будут нормально ворочаться на таких объёмах без "шардирования". Но в случае с монгой, простое шардирование из коробки - это главная киллер-фича. Если вам оно не нужно, то необходимость использовать именно MongoDB чаще всего сомнительна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #121

115. Сообщение от mmrnmhrm (?), 27-Сен-20, 23:31	+/–
приветик ударникам криокамеры https://wiki.termux.com/wiki/Postgresql без рута, регистрации и смс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

116. Сообщение от mmrnmhrm (?), 27-Сен-20, 23:36	+/–
назови, пожалуста, количество записей в хранилище и частоту обращений видел людей, серьёзно считающих 30к записей хайлоадом, которому необходим шардинг постгря такую мелочь перемалывает без индексов, банальным фулсканом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #125

117. Сообщение от ivanpetrov (ok), 28-Сен-20, 00:19	+/–
https://tableplus.com/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

118. Сообщение от Аноним (118), 28-Сен-20, 02:22	+/–
Обязательно нужны. Как минимум, нужно поставить жаву, не удалить её по autoremove, поставить приложение как принято в системе, по правильным путям, с иконками, записями в меню, документацией и манами, а потом обновлять его вместе со всем остальным, а не вспоминать где у тебя по системе распихан протухший софт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

119. Сообщение от Аноним (118), 28-Сен-20, 02:22	+/–
psql. Вы инвалид, зачем вам визуально?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

120. Сообщение от edo (ok), 28-Сен-20, 05:49	+/–
каким это образом по-вашему update (работающий исключительно на сервере) будет таскать данные на клиента и обратно? P. S. обновление json на десятки мегабайт в любом случае боль. jsonb ЕМНИП никак проблему не решает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

121. Сообщение от лютый жабби__ (?), 28-Сен-20, 11:02	+/–
>Если придираться к словам -"реплики редко нужны" -нет, реплики нужны всегда, т.к. время разворачивания бэкапа несколько дней -репликация - это не то же самое что бекап, и не заменяет его хрень пишешь... "простое шардирование из коробки - это главная киллер-фича" ой, мля, ну всё, срочно побежал монгу менять на всех проектах, т.к. я внезапно не использую киллер-фичу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #124

122. Сообщение от Аноним (122), 28-Сен-20, 11:08	–1 +/–
Какой ppa? На дворе 2020 и docker образ PostgreSQL ставится в 3 клика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

123. Сообщение от Аноним (123), 28-Сен-20, 11:28	+/–
Ну так и используй линукс! А вообще, в винде WSL завезли, мб и на нём взлетит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

124. Сообщение от Cykooz (ok), 28-Сен-20, 12:06	+/–
> хрень пишешь... В чём хрень? Если у тебя приложение (или хакеры) испоганит данные в базе, то эти изменения будут во всех репликах базы очень быстро. Т.е. репликация ни каким образом не позволит тебе откатить состояние базы на какой-то момент в прошлом, когда всё было нормально. Для такого нужен бекап. Поэтому я и написал, что репликация не заменяет бекапы. > ой, мля, ну всё, срочно побежал монгу менять на всех проектах, т.к. > я внезапно не использую киллер-фичу Я и не прошу тебя отказываться от Монги в уже написанном проекте (сам уже 8 лет пилю такой). Я говорил исключительно про выбор базы данных для ещё ненаписанного приложения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

125. Сообщение от InuYasha (??), 28-Сен-20, 12:27	+/–
Не помню. Монги занимали порядка 50-100ГБ данных на штуку, к каждой обращалась пара десятков серверов в реальном времени, т.е. непрерывно, забивая пару мегабит - точно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

126. Сообщение от InuYasha (??), 28-Сен-20, 12:29	+/–
Аноны, вы вконец ослепли?? https://www.postgresql.org/media/img/about/press/elephant.png Это логотип!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

127. Сообщение от phil (??), 28-Сен-20, 22:16	+/–
> А вот монга способна этот фокус проделать даже с документами размером в несколько Гб Максимальный размер документа в монге – 16 МБ (ну, если ее не перекомпилять)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #132

128. Сообщение от Виталий (??), 29-Сен-20, 09:20	+/–
>Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка? За тем, что Postgres отжал у Oracle рынок, а это добивает последних. Я еще в 2011-2012 RBC переводил с Oracle на Postgres, экономия была огромной как по лицензиям так и по простоте поддержки и стоимости обслуживания.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

129. Сообщение от andrey (??), 29-Сен-20, 17:30	+/–
https://github.com/parihaaraka/sqt
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

130. Сообщение от Аноним (130), 29-Сен-20, 18:10	+/–
>А чем сейчас модно визуально в базе ковыряться? Можно попробовать Kexi из состава Calligra.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

131. Сообщение от ptr128 (?), 30-Сен-20, 11:49	+/–
Чем легче перенести код с PL/SQL на PL/pgsql - тем больше пользователей это сделают. А практическая бесшовная поддержка иных языков - очень сильное конкурентное преимущество. После длительного общения с MS по поводу активного использования R в MS SQL, они сами рекомендовали перейти на PostgreSQL. Производительность выросла на порядок! Если конкретней, то при необходимости нескольких миллионов вызовов функций на R при обработке данных, вместо 14 часов на MS SQL стали укладываться в 70 минут на PostgreSQL на том же сервере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

132. Сообщение от jOKer (ok), 30-Сен-20, 20:09	+/–
Увеличивать эту константу имеет смысл только есть у вас много ОЗУ, потому что она и выбрана-то была, с тем расчетом, что бы документ в ОЗУ поместился с гарантией. Куда проще (и это официально рекомендованный вариант) использовать для хранения GridFS. В этом случае, документ бьется на чанки, что конечно снижает общую производительность, но не так уж и сильно. Но вот документ при этом, может достигать значительно больших размеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема