The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

"Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от opennews (?), 04-Янв-24, 12:11 
Издание  DB-Engines обновило свой рейтинг популярности СУБД и присудило звание СУБД 2023 года проекту  PostgreSQL, который за год продемонстрировал наибольших рост популярности из 417 отслеживаемых систем. Второе место присуждено облачной платформе Databricks, которая за год поднялась с 19 на 17 место в рейтиге, а третье место занял движок Google BigQuery, который поднялся с 21 на 19 место в рейтинге...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60388

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

5. Сообщение от Аноним (5), 04-Янв-24, 12:24   +/
Что-то SQLite3 и Metakit4 не любят...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #23, #25, #104

6. Сообщение от Аноним (7), 04-Янв-24, 12:25   +17 +/
Уж не потому ли что в одной стране постгрей замещают весь тухлый орацле?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #14, #122

7. Сообщение от Аноним (7), 04-Янв-24, 12:26   –13 +/
Психически здоровые люди в принципе не должны пользоваться SQLite3 ни в каком виде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #8, #15, #119

8. Сообщение от Аноним (5), 04-Янв-24, 12:28   +2 +/
Айфоном пользуешься?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #17

9. Сообщение от Аноним (5), 04-Янв-24, 12:33   +/
А в чём смысл именно базы Oracle (помню, что у оракла есть какая-то очень крутая энтерпрайзная технология на основе очереди событий, огромной библиотеки обработчиков и с возможностью добавлять собственные блоки, но это, наверное, другая история)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #12, #18, #64, #105

10. Сообщение от iPony129412 (?), 04-Янв-24, 12:34   +7 +/
До 2022 работал только с Oracle, но потом что-то случилось, и теперь PostgreSQL
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45

12. Сообщение от Аноним (5), 04-Янв-24, 12:36   +/
А, вспомнил, Oracle BPM называется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

13. Сообщение от Карлос Сношайтилис (ok), 04-Янв-24, 12:36   +1 +/
Странно ставить в один ряд и сравнивать PostgreSQL и Databricks – on-premise приложение и облачную платформу.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

14. Сообщение от Аноним (77), 04-Янв-24, 12:48   +/
>замещают весь

https://www.kommersant.ru/doc/6199827

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #28

15. Сообщение от Аноним (15), 04-Янв-24, 12:49   +/
SQLite используется браузерами для хранения всех данных. Достаточно здорово?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #16, #43

16. Сообщение от Аноним (7), 04-Янв-24, 12:57   +1 +/
Лучши показатель худшего при применения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #29, #131

17. Сообщение от Аноним (7), 04-Янв-24, 12:57   –2 +/
Пользователь скулайта детектед.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #22

18. Сообщение от Аноним (77), 04-Янв-24, 12:59   +1 +/
>в чём смысл именно базы Oracle

https://www.oracle.com/support/

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #30

19. Сообщение от Аноним (19), 04-Янв-24, 13:20   +2 +/
То, чего не должно быть, на 3-м месте.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #66

20. Сообщение от лютый жабби.... (?), 04-Янв-24, 13:24   +1 +/
Всю отбитость этого "рейтинга" демонстрирует его содержимое. Эластиксёрч у вас на 7м месте, а нео4ж на 20м.... ну всё, теперь буду графы эластиком считать (буг0г0г0)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #62, #91

22. Сообщение от YetAnotherOnanym (ok), 04-Янв-24, 13:38   +1 +/
Боишься пользователей скулайта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #26

23. Сообщение от rshadow (ok), 04-Янв-24, 14:00   +/
Для этого надо по рынкам смотреть, ведь они тоже неравномерно друг относительно друга растут. И тогда уже смотреть на лидеров конкретного направления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

25. Сообщение от Аноним (26), 04-Янв-24, 14:07   –1 +/
> Что-то SQLite3

Потому что рейтинг в основном учитывает вопросы и обсуждения. Так как функциональность у SQLite крайне мала по сравнению с серверными СУБД, то и обсуждать там особо нечего.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #36

26. Сообщение от Аноним (26), 04-Янв-24, 14:08   +1 +/
Этак можно каждый раз пугаться, проходя мимо зеркала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27

27. Сообщение от Аноним (26), 04-Янв-24, 14:09   –2 +/
Сильно лучше, чем "в простых текстовых файлах", как завещали основатели UNIX.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #50

28. Сообщение от Аноним (26), 04-Янв-24, 14:11   +1 +/
Любая миграция стоит денег, а банкиры отлично умеют считать деньги.
Естественно, выгоднее будет ничего не мигрировать, а просто поныть и попросить подачек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #123, #194

29. Сообщение от Аноним (29), 04-Янв-24, 14:12   +1 +/
Предлагаешь рядом с каждым браузером MySQL поднимать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #31

30. Сообщение от Аноним (30), 04-Янв-24, 14:23   –2 +/
Так забацали же Postgres Pro, добавили в реестр.
И ты сможешь получить такой же саппорт там. Ну, почти такой же!
Так что даже выиграли!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #32

31. Сообщение от Аноним (31), 04-Янв-24, 14:32   +/
Помню толи в KDE3, только в KDE4 был какой-то музыкальный проигрыватель с хранением данных в MySQL. Пля какая тормознутая жесть это была.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #35, #77, #130

32. Сообщение от Аноним (26), 04-Янв-24, 14:54   +2 +/
Учитывая последние крупные сокращения в Oracle — как минимум, не проиграли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #38

33. Сообщение от Аноним (26), 04-Янв-24, 14:55   +/
Такая же проприетарь, как и оракл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

34. Сообщение от Аноним (34), 04-Янв-24, 15:02   +/
Ура, Firebird рванул вверх!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40

35. Сообщение от Аноним (5), 04-Янв-24, 15:07   +2 +/
Да там и сейчас KOrganizer MariaDB использует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #41, #120

36. Сообщение от Аноним (5), 04-Янв-24, 15:10   –1 +/
Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно. Поэтому многопользовательность и прочие сложности обеспечения консистентности тут не нужны. В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение. Кому надо покомпактнее без сложных SQL-запросов - тому наверное лучше метакит или вообще LMDB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #37, #61

37. Сообщение от Аноним (37), 04-Янв-24, 15:17   –1 +/
>>Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно.

Это не так...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #48

38. Сообщение от Аноним (77), 04-Янв-24, 15:19   +2 +/
Эх, знал бы Ларри, как за него тут переживают, прослезился бы... наверное :)
https://www.datacenterdynamics.com/en/news/oracles-larry-ell.../
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

39. Сообщение от Аноним (37), 04-Янв-24, 15:23   +2 +/
вообще странный рейтинг да
там например есть и Postgres и PostGIS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

40. Сообщение от Аноним (37), 04-Янв-24, 15:24   +1 +/
чему Вы радуетесь ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #46, #85

41. Сообщение от Аноним (41), 04-Янв-24, 15:42   +2 +/
Надо для программы ведения заметок прикрутить Оракл с партициями, кучей индексов, rman по крону запускать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

42. Сообщение от Аноньимъ (ok), 04-Янв-24, 15:51   –7 +/
> PostgreSQL

По какой-то причине очень любима ентерпрайз галерами.
Подозреваю по причине сложности настройки и эксплутации, можно посадить клиента на поддержку по самые нехочу.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #47, #71, #103

43. Сообщение от Аноним (43), 04-Янв-24, 16:19   +2 +/
Используется любыми программами, которым не похер на сохранность данных. Браузерам, кстати, похер -- они повреждаются и обнуляются только так, несмотря на скулайт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #98, #146

44. Сообщение от Карлос Сношайтилис (ok), 04-Янв-24, 16:37   +/
> По какой-то причине очень любима ентерпрайз галерами.

По причине бесплатности, за поддержку можно брать как за оракл, но накладных расходов меньше

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #49

45. Сообщение от Аноним (26), 04-Янв-24, 16:42   +4 +/
На самом деле, процесс шёл с 2014 года, просто с 2022 он ускорился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

46. Сообщение от Аноним (26), 04-Янв-24, 16:43   +/
Что открылся путь из царства теней в мир живых?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

47. Сообщение от Аноним (26), 04-Янв-24, 16:47   +/
> Подозреваю по причине сложности настройки и эксплутации, можно посадить клиента на поддержку по самые нехочу.

Нет, по причине отсутствия опенсорсных конкурентов.
Мускуль — менее универсален, у него узкая ниша лендингов и мелких интернет-магазинов с десятком посетителей в день. За рамками этой ниши начинаются такие сложности, что дешевле на постгрес переехать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #53, #58, #70, #92

48. Сообщение от Аноним (26), 04-Янв-24, 16:48   –1 +/
Ну попробуйте из двух приложений одновременно писать в одну базу данных SQLite.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #51, #111

49. Сообщение от Аноним (26), 04-Янв-24, 16:49   +/
Так и мускуль бесплатен, но почему-то используется в основном для друпала и вордпресса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #68

50. Сообщение от Аноним (26), 04-Янв-24, 16:51   +1 +/
^^ На самом деле, этот комментарий должен был быть в соседней ветке. Акела промахнулся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

51. Сообщение от Аноним (5), 04-Янв-24, 16:52   –1 +/
Ну вообще можно и делается, но если такой use case не является целевым, то лучше заблокировать базу эксклюзивно, и производительность операций с ней вырастет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #60

52. Сообщение от Аноним (5), 04-Янв-24, 16:53   +/
Use caseы разные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

53. Сообщение от Аноним (53), 04-Янв-24, 17:43   +1 +/
Так и смысл тогда мумкуль брать? Для пары посетителей хватит и дефолтной настройки постгри
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #55

54. Сообщение от sig11 (ok), 04-Янв-24, 17:52   +/
А куда делись dBase, FoxPro, Clipper? Да они со своим форматом DBF порвут все эти SQL-и по всем параметрам...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #56, #57, #74, #170

55. Сообщение от Аноним (26), 04-Янв-24, 18:02   +1 +/
> Так и смысл тогда мумкуль брать?

Потому что PHP-разработчики, которые за $2/час подпилят друпал под нужды малого бизнеса, обычно умеют подключаться только к мускулю.

> Для пары посетителей хватит и дефолтной настройки постгри

Не все это знают. Типовому PHP-разработчику за $2/час не хочется много думать и что-то учить, ему хочется фигак-фигак и в продакшн.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

56. Сообщение от Аноним (26), 04-Янв-24, 18:06   +2 +/
Не порвали, поэтому их тут и нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

57. Сообщение от Аноним (31), 04-Янв-24, 18:13   +/
Paradox'а тоже нету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

58. Сообщение от Аноньимъ (ok), 04-Янв-24, 18:17   +/
Какие сложности начинаются с мусклом?

Я недавно на нем небольшую базу для аналитики гонял, что-то ок 60Гб. Оно вообще ну очень быстро работает. Что там такое должно быть чтобы мускл затык, а постгря справилась?

Кстати видел эту постгрю в энтерпрайзных галерах. Они умудряются её реально тормозить на десятках и сотнях запросов, потому что DB Инженер - это видимо уже немодно и ненужно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #59, #82

59. Сообщение от Аноним (26), 04-Янв-24, 18:21   +1 +/
Кстати, это вы тот PHP-разработчик, который допиливает друпал на $2/час?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #67, #69

60. Сообщение от Аноним (37), 04-Янв-24, 18:51   –3 +/
да. имеено поэтому sqlite значительно превосходит в скорости записи и чтения все серверные субд, но не во всех случаях может бытьиспользован
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #63

61. Сообщение от Аноним (180), 04-Янв-24, 18:55   +2 +/
>  В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение.

Ещё один размороженный. Добро пожаловать в 2024-ый, уже 20 лет прошло с твоей заморозки, мир сильно изменился

https://www.sqlite.org/version3.html
https://www.sqlite.org/fileformat.html

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #73

62. Сообщение от Аноним (26), 04-Янв-24, 18:57   +1 +/
> теперь буду графы эластиком считать

А я даже знаю контору, которая каждое ребро графа сохраняет как документ в эластике (причем версии 2.4).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

63. Сообщение от Аноним (26), 04-Янв-24, 19:01   +/
> имеено поэтому sqlite значительно превосходит в скорости записи и чтения все серверные субд

Пользователи Redis с вами не согласятся.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #132

64. Сообщение от Аноним (180), 04-Янв-24, 19:13   +/
Похоже, что undo segments в Oracle DBMS более правильное техническое решение, чем аналог в PG. В Oracle больше отладочных данных для поиска затыков, больше статей по оптимизациям. С другой стороны, в PG больше типов данных, но для счёта денюжек это не фича. В принципе можно жить хорошо и с PG если развивать ИС с нуля на PG. Но миграция может оказаться очень болезненной и проблемной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

66. Сообщение от Аноним (180), 04-Янв-24, 19:15   +2 +/
То, чего не должно быть, на 2-ом месте - php в мире СУДБ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #79, #86

67. Сообщение от Аноньимъ (ok), 04-Янв-24, 19:17   +/
Нет.

Я PHP в его лучшие годы не трогал. Концепцию смеси серверного кода с html разметкой считаю ужасной, и не безопасной.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

68. Сообщение от Аноним (180), 04-Янв-24, 19:21   +4 +/
Потому что MySQL криво спроектирован, от реализации SQL и до методов настройки хранилищ. PG это коробочное решение с корректным SQL и с ровно одним рабочим бэкэндом со всеми фичами и плюсами такого подхода. Также PG по фичам и SQLю ближе к другим коммерческим СУБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #80, #87, #113

69. Сообщение от Вы забыли заполнить поле Name (?), 04-Янв-24, 19:24   +/
Если работать 24 часа в день, то нормально :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

70. Сообщение от Аноньимъ (ok), 04-Янв-24, 19:45   –1 +/
Ну вот например:

https://diginomica.com/look-servicenow-managing-85000-databa...

Вроде всё отлично у них за пределами 10 посетителей в день.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #72

71. Сообщение от kernel (??), 04-Янв-24, 19:47   +/
Странные ваши суждения, работаю и с mysql и с pg. Базы занимают терабайты Использую для разных вещей просто потому, что у них разная архитектура и есть места, где pg выигрывает, есть и где mysql. Но в общем-то, с большинством данных они справляются примерно одинаково. Если, конечно, структуру нормальный инженер проектировал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #76, #81, #90

72. Сообщение от kernel (??), 04-Янв-24, 19:50   +3 +/
На самом деле, при таких нагрузках у mariadb были проблемы. У меня несколько сотен тысяч баз, и были баги, на которые делал багрепорты. К счастью, все эти багрепорты уже достаточно давно закрыты. Но подебажить пришлось основательно, чтобы разработчики смогли найти причины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

73. Сообщение от Аноним (5), 04-Янв-24, 20:03   +/
>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-полями, какое-то время подержать поддержку в коде самой базы, потом какое-то время добавить автоконвертацию, а потом старый формат вообще дропнуть. Кому надо - сконвертят.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #75, #133, #178

74. Сообщение от Аноним (5), 04-Янв-24, 20:05   +1 +/
Свой вижуал бэйсик проприетарный выкинуть можете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

75. Сообщение от Аноним (75), 04-Янв-24, 20:30   –1 +/
Ну так выпусти!
Тут тебе никто ничего не должен...
Я дажe название подскажу: "SQLiteLE"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

76. Сообщение от Аноньимъ (ok), 04-Янв-24, 20:32   –1 +/
> с большинством данных они справляются примерно одинаково

С вами я могу только солглашаться. Всегда интересно послушать мнение профессиорнала.

> Если, конечно, структуру нормальный инженер проектировал.

Абсолютно с вами согласен.

> Странные ваши суждения

Ну, я не профи в базах данных. Говорю только то, что наблюдаю сам.
Вижу повышенную любовь к постгре у IT галер (в особо извращенном хоррор жанре, с датабейс микросервис и транзакционал датабейс микросервис)

Так как считаю, что, в производительности большой разницы нет при правильной настройке, то, предпологаю, что это конкретно связанно со сложностью поддержки и внедрения.
Возможно связь иная, возможно какие-то стандартные курсы девопсов учат кокнретно постгре. Может у постгри какой-то особо удобный докер образ. А может это связанно с наличием кучи расширений к постгре на которые завязанны какие-то старндартные ентерпрайз решения.
А может это деформация тех галер о которых мне известно.

Для меня БД - всегда была вспомогательным интрументом. Как-то смотрел на PG но обнаружил путь от "установил пакет" до "подключился и работаешь" слишком сложным.
Когда-то давно работал немного с Ораклом и МС(в рамках дотнета), но для себя быстро перешёл на мускл и теперь Марию. Оно просто работает сразу, в моём опыте. Причём отлично, удалось избежать новомодных timeseries баз. Сжатие страниц? то-же работает отлично, для моих нужд самое оно. По моему в PG аналогичного механизма нет?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #83, #93

77. Сообщение от Аноним (77), 04-Янв-24, 20:55   +1 +/
https://www.mysql.com/customers/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

79. Сообщение от Аноним (26), 04-Янв-24, 21:04   +/
Скорее, аналог JavaScript.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

80. Сообщение от Аноним (26), 04-Янв-24, 21:09   +/
Насколько я помню, у мускуля тоже остался ровно один рабочий бэкенд (не считая одного проприетарного).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

81. Сообщение от Аноним (26), 04-Янв-24, 21:11   +/
> Использую для разных вещей просто потому, что у них разная архитектура и есть места, где pg выигрывает, есть и где mysql.

Прямо даже интересно, в каком месте может выиграть mysql?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #106

82. Сообщение от Аноним (26), 04-Янв-24, 21:16   +/
> Я недавно на нем небольшую базу для аналитики гонял, что-то ок 60Гб. Оно вообще ну очень быстро работает. Что там такое должно быть чтобы мускл затык, а постгря справилась?

Использовать OLTP для аналитики — уже многое о вас говорит.

Наверное, "ну очень быстро" — это когда запрос отрабатывает за выходные?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #124

83. Сообщение от Аноним (26), 04-Янв-24, 21:22   –1 +/
> Как-то смотрел на PG но обнаружил путь от "установил пакет" до "подключился и работаешь" слишком сложным.

Весьма наглядная иллюстрация тезиса

> Типовому PHP-разработчику за $2/час не хочется много думать и что-то учить, ему хочется фигак-фигак и в продакшн.

Причем, в отсутствие особых требований этот путь может быть нулевым, так как постгрес очень неплохо работает с настройками по умолчанию.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

85. Сообщение от Аноним (34), 04-Янв-24, 21:35   +1 +/
Что Firebird рванул вверх, неужели не ясно? Ну ты и тупица!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #89

86. Сообщение от Tron is Whistling (?), 04-Янв-24, 22:24   –6 +/
Причём с феерическим отрывом от хламвари, которая на 4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

87. Сообщение от Tron is Whistling (?), 04-Янв-24, 22:26   –5 +/
PG - это очередная глорификация DBF, поэтому он идёт нафиг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #88

88. Сообщение от Аноним (26), 04-Янв-24, 22:50   +1 +/
С таким потрясающим знанием матчасти лесом идёте вы.
Увы и ах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #117, #118

89. Сообщение от Аноним (26), 04-Янв-24, 22:52   +/
А что в этом радостного, если не секрет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #196

90. Сообщение от Аноним (43), 04-Янв-24, 23:11   +/
>Базы занимают терабайты

Ну это не серьёзно, уровень sqlite ведь.

>справляются примерно одинаково

Ну я и говорю, зачем все эти навороты, когда это задачи для sqlite?

>структуру нормальный инженер проектировал

Ну тут не структурой единой, понятное дело, но бездумный sqlite может не показывать достаточной производительности под приличной нагрузкой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #94

91. Сообщение от fuggy (ok), 04-Янв-24, 23:34   +/
Там в полной версии таблички Database Model написана. Так что никого ты не переиграл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

92. Сообщение от fuggy (ok), 04-Янв-24, 23:42   +/
На самом деле у MySQL намного больше универсальности чем ожидается. У неё несколько моделей хранения и можно для каждой таблицы выбрать разную. Настоящие физические кластерные индексы. В PostgreSQL же только одна модель хранения, на которую все вечно жалуются что она пухнет. Вот когда добавят минимум ZHeap, тогда и можно говорить об универсальности. Так что популярность PostgreSQL не связана с универсальностью. Скорее с расширяемостью, соблюдением стандартов, скоростью развития.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #95, #100

93. Сообщение от fuggy (ok), 04-Янв-24, 23:57   +2 +/
PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL. Лучше поддержка разных типов данных JSON, массивов, енумов. Больше типов индексов, есть частичные, функциональные, индексы для геометрических типов данных. Продвинутое управление ролями, даже есть row level security. Так что плюсы в использовании PostgreSQL есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #97, #108, #126

94. Сообщение от Аноним (26), 05-Янв-24, 00:07   +/
> Ну это не серьёзно, уровень sqlite ведь.

Не надо тут, уровень sqlite — не меньше сотни петабайт!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #96

95. Сообщение от Аноним (180), 05-Янв-24, 00:11   +/
^ О, ловите php-шника за $2/час
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #125

96. Сообщение от Аноним (43), 05-Янв-24, 00:12   +/
Не уверен, там лимит около 250 терабайт. Правда, я не слышал, чтобы кто-нибудь больше ~20 задействовал, но, очевидно, что запас хороший остаётся при этом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

97. Сообщение от Аноним (180), 05-Янв-24, 00:14   +1 +/
Ну ок, повысим до php-шника за $8/час
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

98. Сообщение от Аноним (7), 05-Янв-24, 00:19   +/
Похер как раз скулайту. Потому что он не подходит для данной задачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #99

99. Сообщение от Аноним (43), 05-Янв-24, 00:25   +/
Идеально подходит и обеспечивает абсолютную надёжность и защиту от потери бесценных данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

100. Сообщение от Аноним (7), 05-Янв-24, 00:27   –1 +/
Ты сам ответил на свой вопрос. Универсальность это плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

101. Сообщение от Вы забыли заполнить поле Name (?), 05-Янв-24, 00:32   +5 +/
У постгреса все хорошо:

* опенсорс
* нормальная лицензия, которая позволяет без проблем делать облачные решения (привет, монго)
* проверена временем и нагрузками
* есть специалисты
* для любителей обмазаться json все есть
* что не маловажно для РФ, что postgrespro входит в Единый реестр, имеет сертификат ФСТЭК

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #102, #109, #164

102. Сообщение от Вы забыли заполнить поле Name (?), 05-Янв-24, 00:33   +4 +/
Забыл добавить

* дока отличная
* расшираяемость отличная
* написана на божественной сишечке

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #112

103. Сообщение от Аноним (103), 05-Янв-24, 00:37   –1 +/
тебе, наверное, больше подходит решение от ms, т.к. пишешь на шарпе? И почему нас должна интересовать проприетарщина?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #197

104. Сообщение от пох. (?), 05-Янв-24, 00:50   +1 +/
вопросы про sqlite просто не попадают в статистику, кроме совсем уж нубов.

И те если не после первого попадания то раза с десятого хотя бы уже обычно дальше sqlite.org с ними и не ходят.

А "у меня кончилось место на постгрезовом диске, штаделаааатьпамагиитя" - каждый день по сто тыщ.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #134

105. Сообщение от пох. (?), 05-Янв-24, 00:55   –2 +/
> А в чём смысл именно базы Oracle

в том что она как правило - работает.
А когда все же приходит с ora006 - можно обратиться в техподдержку и тебе индус популярно объяснит что сравнивать содержимое xml-атрибута вообще говоря можно, но для этого атрибут хотя бы в этом xml должен быть ;-)

А если тебе нужна просто реляционная субд - то обычно и mysql достаточно (ну или вовсе sqlite)

И никаких тебе вакуумов которые ну уже совсем окончательно победили и объявили deprecated, но опять что-то помешало.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #156, #165

106. Сообщение от пох. (?), 05-Янв-24, 00:58   +1 +/
миллион inserts/s в базку key-value

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

107. Сообщение от Аноним (108), 05-Янв-24, 05:44   –1 +/
Mysql лучше уже тем, что проще. И она работает. Большая часть претензий к ней из времён myisam по умолчанию. То есть было актуально двадцать лет назад.
Да, у большинства пихающих постгрю везде нет и не будет таких данных, чтобы она была прямо необходима. Берут на вырост, чтобы показать главным образом себе, какие они крутые специалисты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #136, #144

108. Сообщение от Аноним (108), 05-Янв-24, 05:50   +1 +/
Все эти плюшки нужны только если тащите логику приложения в слой хранения данных.
Обычно принято дублировать логику. То есть она и в базе, и в приложении. Зачем этот БДСМ нужен, каждый ответит для себя сам.
У кого-то это способ защиты от написанного джунами кода, у кого-то одержимость контролем всего и вся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #147, #173

109. Сообщение от Аноним (108), 05-Янв-24, 05:52   +/
Все так хорошо, что его надо постоянно навязывать и писать в интернете проповеди о его превосходстве.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #159, #163, #189

110. Сообщение от Аноним (110), 05-Янв-24, 06:07   +2 +/
> PostgreSQL названА СУБД
> PostgreSQL уже признавалАСЬ СУБД года

Вспоминаем, как расшифровывается "СУБД".

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #114

111. Сообщение от Антонимусс (?), 05-Янв-24, 07:37   +/
`PRAGMA journal_mode = wal2;` и пишите сколько нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

112. Сообщение от Антонимусс (?), 05-Янв-24, 08:28   –2 +/
У PostgreSQL настолько все замечательно, что Google год назад получили прирост производительности в 100 (sic!) раз на ровном месте, просто переписав там слой хранения данных. Называется AlloyDB.

Существует масса паразитических контор, которые льют в уши насколько PG весь такой бесплатный Open Source, а потом стригут с бизнеса бабло за пропитанные патчи, без которых эта шарманка толком не работает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #142, #162

113. Сообщение от Антонимусс (?), 05-Янв-24, 08:43   +/
MySQL спроектирован просто офигенно, а инженеры из Oracle потом залечили детские болячки - эти ребята разбираются в базах и хорошо знают свое дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #157

114. Сообщение от Аноним (114), 05-Янв-24, 09:15   +/
не нужно додумывать того, чего нет, если бы приписали "СУБД" тогда бы и изменился род.

"PostgreSQL назван"
"проект PostgreSQL назван"
"СУБД PostgreSQL названа"
"система PostgreSQL названа"

Тоже самое с компаниями:
"Компания Canonical опубликовала"
"Canonical опубликовал"
"Mozilla опубликовала"


"Енисей вышел из берегов"
"река Енисей вышла из берегов"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #115, #116, #121

115. Сообщение от Аноним (110), 05-Янв-24, 09:24   +/
Вы реально не видите слова "СУБД" в моём начальном комменте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #128

116. Сообщение от Аноним (110), 05-Янв-24, 09:28   +/
"PostgreSQL названа системой управления базами данных 2023 года"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #127

117. Сообщение от Tron is Whistling (?), 05-Янв-24, 09:44   –2 +/
Ну так чё там, страничную организацию и переиспользование страниц уже добавили, или всё ещё построчник и вакуумы? :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #139, #158, #167

118. Сообщение от Tron is Whistling (?), 05-Янв-24, 09:49   +/
Схему на ходу менять можно, или надо все эннадцать терабайт имеющихся данных перелопачивать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

119. Сообщение от anonymous (??), 05-Янв-24, 10:02   +/
Лучше бы, конечно, gdbm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #151, #152

120. Сообщение от Аноним (120), 05-Янв-24, 10:11   +/
Ох да... Как-то органайзер искал, решил на этом остановиться, пока на процессы не посмотрел...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

121. Сообщение от Аноним (110), 05-Янв-24, 10:50   +/
> "Canonical опубликовал"
> "Mozilla опубликовала"

Миша и Вова заканчиваются на А - значит, их род женский?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #129

122. Сообщение от Аноним (123), 05-Янв-24, 11:05   +1 +/
Орокле в лицензии прописали что им обязаны предоставить доступ на любой объект, включая военный и закрытый город и конечно же они посланы.
Там даже запрещать бесполезно ввиду неприемлемой лицензии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #135

123. Сообщение от Аноним (123), 05-Янв-24, 11:06   +/
Не все банкиры одинаково сообразительны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

124. Сообщение от Аноньимъ (ok), 05-Янв-24, 11:30   +/
> Использовать OLTP для аналитики — уже многое о вас говорит.

Если оно работает, и каши не просит - то всё отлично просто.
Перестанет хватать - разверну что-то более серьездное. Но не постгрю.

> Наверное, "ну очень быстро" — это когда запрос отрабатывает за выходные?

За доли секунды.

Вообще когда я стат анализом занимался, у нас система на нек сценариях по пол дня думала, в штатах жлобились серверу выделить больше памяти, и оно несщадно свопало. Не велика беда.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #215

125. Сообщение от Аноньимъ (ok), 05-Янв-24, 11:31   –1 +/
> О, ловите php-шника за $2/час

Поймал тебя дорогой. Полезай в мешок.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

126. Сообщение от Аноньимъ (ok), 05-Янв-24, 11:43   –1 +/
> Лучше поддержка разных типов данных JSON

Это зло.

> PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL.

Разверните.

> индексы для геометрических типов данных.

https://mariadb.com/kb/en/geographic-geometric-features/

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #148

127. Сообщение от Аноним (114), 05-Янв-24, 11:48   +/
По вашему должно быть "АвтоВАЗ названа самой убыточной компанией года", "АвтоВАЗ снова стала российской компанией" и "АвтоВАЗ получила годовой убыток". Ухо не режет? Для вас русский язык точно родной?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

128. Сообщение от Аноним (114), 05-Янв-24, 11:49   +/
Вы реально не видите отсутствие уточняющего слова СУБД _перед_ PostgreSQL в обсуждаемом тексте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

129. Сообщение от Аноним (114), 05-Янв-24, 11:50   +/
И при чем здесь окончание?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

130. Сообщение от Аноним (130), 05-Янв-24, 12:11   +/
Да, это Amarok. Серверную СУБД использует для хранения музыкальной коллекции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

131. Сообщение от Аноним (131), 05-Янв-24, 12:27   –1 +/
Прикол в том, что такие, как ты, никогда не смогут сделать всё то что в прикладном софте делается через SQLite дёшево и сердито, не говоря уже о "лучшем применении", простоте работы с этим, надёжности, производительности, размерах, портабельности...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #180

132. Сообщение от Аноним (131), 05-Янв-24, 12:30   +/
Бенчмарки в студию. Но только чтобы эти данные вот прям сохранялись, а не "мы тут что-то в память прихранили, но если свет моргнёт, то продолбаем вообще всё, ещё и старые данные развалим"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #149

133. Сообщение от Аноним (131), 05-Янв-24, 12:31   +/
Звучит как боль чувачка, который не смог в ORM и нормальные миграции
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #153

134. Сообщение от Аноним (131), 05-Янв-24, 12:33   +/
Всё ещё лучше чем "мы использовали на проде MS SQL CE и БД перевалила за 4Гб, как жить дальше?".
Про окакл вообще пугающе дофига вопросов (или правильнее читать проблем?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #145

135. Сообщение от Аноним (7), 05-Янв-24, 12:37   +/
Протри глаза это Оракл ушел. Ораклом пользовался или даже пользуется даже Центробанк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #166

136. Сообщение от Аноним (7), 05-Янв-24, 12:43   +4 +/
Берут на вырост чтобы не заниматься лишней миграцией из майсикуэль в постгресс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

139. Сообщение от Аноним (139), 05-Янв-24, 13:28   +/
https://www.opennet.ru/opennews/art.shtml?num=59453
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #141, #143

141. Сообщение от Tron is Whistling (?), 05-Янв-24, 14:24   +/
Целый навесной бета-костыль, надо же.
Ну, может, такими темпами лет через 20 и станет нормальной DBMS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

142. Сообщение от нах. (?), 05-Янв-24, 14:52   +3 +/
> Называется AlloyDB.

и работает только в специфическом use case гугля.
Как обычно.

Ты бы мог так же ускорить oracle, если бы переписал его слой хранения исключительно под свою любимую key-value - но они не дадут тебе такой возможности.

> Существует масса паразитических контор, которые льют в уши насколько PG весь такой бесплатный
> Open Source, а потом стригут с бизнеса бабло за пропитанные патчи, без которых эта шарманка
> толком не работает.

вот видишь - конь-куренция! А у орацла - контора одна, и другого источника патчей у тебя нет.
А без них шарманка тоже не очень. И еще и с паспортом неправильной страны сразу следом за кораблем отправляют.

Но проблема что сколько ту опенсорсную поделку не корми - у орацла все равно и толще и длиннее.

И vacuum почему-то не нужон.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #184

143. Сообщение от нах. (?), 05-Янв-24, 14:54   +/
дык, эта... статус паблик-беты не меняется уже пол-года. Когда там еще эти пчьолы прилетят - мы уже наверное в рай попадем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #175

144. Сообщение от Аноним (26), 05-Янв-24, 14:57   +2 +/
> Mysql лучше уже тем, что проще. И она работает.

По обоим критериям проигрывает постгресу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

145. Сообщение от нах. (?), 05-Янв-24, 15:02   +/
э... я боюсь даже вводить такой запрос.

(ms sql ce - на минуточку, в девичестве "ms sql for windows CE". Для запуска на пда о 64 мегабайтах оперативы.)

> Про окакл вообще пугающе дофига вопросов (или правильнее читать проблем?)

дык - "чтоб денег никому не платить".
Особенно в свете проблем одной интересной страны без международно признанных границ.

Пользоваться им без доступа к течнету/otr - такое себе. Т.е. надо понимать что это нифига не коробочный продукт, точнее говоря - для тех кому он на самом деле продается - не может быть коробочного продукта.

Если его вместо mysql использовать - то вряд ли ты осчастливишь статистику такими запросами - он просто будет работать, даже неинтересно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

146. Сообщение от нах. (?), 05-Янв-24, 15:06   +1 +/
не хотел бы тебя огорчать, но обнуляется и повреждается твоя любимая мразила именно потому что вместо sqlite по каким-то них-причинам ее рабы перешли на самодельные xml и нескучные json.

(Вот например эта - с которой пишу - не может запомнить размеры окон при перезапуске. Причина хорошо известна, как лечить - никто не знает. Пока эта инфа хранилась в sqlite - все просто работало.)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

147. Сообщение от fuggy (ok), 05-Янв-24, 15:07   +1 +/
Да, а потом будем тянуть тысячи строк в браузер, чтобы по новой изобрести алгоритмы сортировки и джойнов. Не всегда с базой работает только одно приложение. Ещё есть тестировщики и разработчики, которые могут напрямую в бд вставить что-то. И что в каждое приложение добавлять логику ограничений, проверки уникальности, внешние ключи. Есть схема данных и зачем это тащить в логику приложения. Разгребать потом дубликаты и искать проблемы где забыли добавить внешние ключи намного сложнее, чем мнимый выигрыш от того что бд будет работать быстрее, если мы не будем использовать внешние ключи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

148. Сообщение от fuggy (ok), 05-Янв-24, 15:40   +/
>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 или агрегатные функции. С одной стороны может удобно, с другой может выдать значение из любой строки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #150, #177

149. Сообщение от Аноним (37), 05-Янв-24, 16:01   +/
более того я уверен что sqlite в режиме inmemory уделает redis очень просто )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

150. Сообщение от Аноньимъ (ok), 05-Янв-24, 16:03   +/
Не знаю, можно или нельзя. Я не большой сторонник стандартов ради стандартов. И не знаю насколько им следует например МС или Оракл.

Вообще с этим жсоном наверное моя главная проблема в том, что табличная СУБД пытается зачем-то быть объектной, там ещё и графовые движки есть.

Хотя и гонять жейсон по сети в базу и обратно видится идеей довольно странной.
Но это я так, модные молодёжные BD вообще по http работают.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #154

151. Сообщение от Аноним (151), 05-Янв-24, 16:44   +/
https://www.gnu.org/software/gdbm/ редиректит (302) на https://www.gnu.org.ua/software/gdbm/ , а в РФ блокируют сайты в ua-доменах все подряд, включая gnu.org.ua. Не раз сталкивался с тем, что нужно скачать дейташит, а он зачастую на ua-сайте, ни одного политического сообщения на странице нет - а сайт всё равно заблочен просто за то, что в ua-домене.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

152. Сообщение от Аноним (151), 05-Янв-24, 16:49   +/
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.

ффтопку.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #171, #172

153. Сообщение от Аноним (153), 05-Янв-24, 17:02   +1 +/
ORM - это говно, которое имеет смысл использовать только поверх key-value хранилища. Потому что смысл ORM - это просто прозрачное для прогркммиста получение данных по ключу и сохранение данных по ключу, а все операции делаются на стороне приложения. Для этого движок SQLite с индексами, оптимизацией сложных запросов и оверхедом на всё это просто избыточен: сам ORM строить подобные запросы не умеет. SQL используют там, где надо не просто хранить бизнес-данные, но ещё эффективно их выбирать, пересылая только те, что нужны, и модифифировать, избегая ненужных запросов. Поэтому у меня используется ванильный SQLite + ООП-обвязка + мои кастомные запросы, оптимизированные вместе со схемой. Но не ORM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #174, #176, #179

154. Сообщение от fuggy (ok), 05-Янв-24, 17:20   +2 +/
Вообще-то PostgreSQL разрабатывался как объектно-реляционная, не путать с документной, а не просто реляционная. Там можно определять пользовательские типы данных, например валютный тип, где сумма и код валюты лежат в одной колонке, чтобы работать атомарно, и определять функции над новыми типами. Графовым чаще всего нужен свой язык, так как SQL плохо подходит.
Я тоже согласен что молодёжным базам работать по текстовому протоколу, вместо бинарного это менее производительно. Это ж для каждой строки нужно все заголовки колонок передавать, очень неэффективно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

155. Сообщение от Аноним (155), 05-Янв-24, 17:24   +/
Десятилетиями работаю с PHP и MySQL. На всяких работах работал, везде MySQL. Только в одной госконторе были oracle, роstgres да и то частично.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #161

156. Сообщение от Аноним (26), 05-Янв-24, 17:59   +/
> А если тебе нужна просто реляционная субд - то обычно и mysql достаточно (ну или вовсе sqlite)

Видимо, ни с чем сложнее KDEшных приложений вы дела не имели.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

157. Сообщение от Аноним (26), 05-Янв-24, 18:01   +1 +/
Так "офигенно спроектирован" (уже смешно, кстати) или всё-таки имел "детские болячки"?

"Во-первых, я кувшин не брала, во-вторых, уже вернула, в-третьих, он уже был с трещиной"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

158. Сообщение от Аноним (26), 05-Янв-24, 18:08   +1 +/
> Ну так чё там, страничную организацию и переиспользование страниц уже добавили

Как и было отмечено выше, знание матчасти у вас действительно около нулевое (если что, страничная организация данных используется в потсгресе с начала времён).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #191

159. Сообщение от Аноним (26), 05-Янв-24, 18:10   +/
То-то все комментарии здесь забиты проповедями про "замечательный mysql", про его простую и прекрасную архитектуру, но без конкретики и вообще подозрительно напоминающие маркетинговую лапшу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

161. Сообщение от Аноним (170), 05-Янв-24, 18:32   +5 +/
Сочувствую! Так и не поработал на нормальных СУБД... :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #201

162. Сообщение от Аноним (170), 05-Янв-24, 18:44   +/
Я не понимаю, почему плебеи вроде вас (в самом прямом ИТ-смысле как "люди, крутящиеся вокруг самых дешевейших решений") рассуждают о Гугле? Кто вы и кто они - не чувствуете разницу? Гугл, M$, Oracle, Amazon... да даже Stack Overflow НАМНОГО круче, крупнее и мощнее любых ваших проектов. Соотв. с вашей позиции вообще нельзя ничего примерять на себя из того, что творят "столпы ИТ". Ваши два филиала бухгалтерии ПРЕКРАСНО справятся под любой из современных СУБД, нет даже никакого смысла спорить. Кому по вкусу PG - ради бога, ставьте, ОН ТОЖЕ РАБОТАЕТ. Вам гугловские патчи точно не нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #186

163. Сообщение от Аноним (170), 05-Янв-24, 18:46   +1 +/
Никогда такого не слышал. Любые топики про постгрес прекрасно обходятся тем, что люди УЖЕ используют Постгрес и им ДОВОЛЬНЫ. Самая агитутская технология в ИТ - это раст. ВЕЗДЕ где можно влезают со своим недоязыком и постоянно капают в уши "работой с памятью". Можно подумать, это единственная проблема софта!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

164. Сообщение от лютый жабби.... (?), 05-Янв-24, 18:54   +/
>что не маловажно для РФ, что postgrespro входит в Единый реестр, имеет сертификат ФСТЭК

ты не поверишь, монго в нем тоже есть (под каким-то клованским названием типа аурадб чтоли). правда они настолько не парились и не палились, что даже имена прог (mongodump итд) не переименовывали )

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

165. Сообщение от Аноним (165), 05-Янв-24, 18:55   +2 +/
Ничего не понял.

>в том что она как правило - работает

SQLite работает. Postgres работает. MariaDB/InnoDB работает. LMDB работает. MongoDB работает. Neo4J работает. Любая успешная база работает. Не вижу в этом аспекте никаких отличий.

>можно обратиться в техподдержку и тебе индус популярно объяснит что сравнивать содержимое xml-атрибута вообще говоря можно, но для этого атрибут хотя бы в этом xml должен быть ;-)

У всех крупных баз есть компании, оказывающие консультации за деньги, зачастую - те же компании, что базу и разрабатывают. Не вижу отличий. Также не понятно, нахрена эти консультации, если такие вещи должен знать сам разраб приложения, использующего базу. А если не знает - всё на StackOverflow есть.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #181, #210

166. Сообщение от Аноним (166), 05-Янв-24, 18:58   –1 +/
Ещё раз, нахрена именно оркал? SQL везде примерно одинаков. За что именно платят оркам сотни нефти за лицензии на базы? Что там такого в этой DBMS, что нет ни у кого другого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #169, #183, #195

167. Сообщение от Аноним (180), 05-Янв-24, 19:24   +/
Почти все реляционные СУБД работают со страницами, а внутри, внезапно, строки. Везде есть переиспользование страниц, везде есть чистка мусора (т.е. VACUUM) и мусор в страницах. Даже многие нереляционные СУБД такие. Проблема PG заключается только в том, что он много мусорит и сильно фрагментирует страницы из-за отсутствия undo сегмента. А именно, всегда добавляет изменённые данные к новым вместо замены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #192

169. Сообщение от пох. (?), 05-Янв-24, 19:30   –1 +/
> Ещё раз, нахрена именно оркал? SQL везде примерно одинаков.

эксперт опеннета пожаловал.

> За что именно платят оркам сотни нефти за лицензии на базы? Что там такого

вот когда ты это наконец узнаешь - тогда и приходи.

Ну или хотя бы с "примерно одинаковым SQL" разберешься.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

170. Сообщение от Аноним (170), 05-Янв-24, 19:31   +/
Они канули в лету, но что-то мне говорит, что их новая "волна популярности" ещё впереди. Есть мириады мест, где "многопользовательность" нужна сугубо локально, в пределах офиса. Спрашивается, зачем им умопомрачительные по сложности транзакции, блокировки, файловеры, зеркала, когда всё прекрасно работает на уроне 3 конекшенов и SQLite? Другой вопрос, что подход к "файл-ориентированным СУБД" должен быть современный, модульный, масштабный, тогда и реализации появятся очень даже вкусные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #198

171. Сообщение от lockywolf (ok), 05-Янв-24, 19:39   +/
Специально для тебя есть berkeley db.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

172. Сообщение от Аноним (43), 05-Янв-24, 19:44   +/
Не ной, это одна из реализаций. И никто не запрещает тебе отправлять в неё данные через system. Если прям так хочется воровать чужой код, возьми какую-нибудь cdb, она лицензирована как общественное достояние. Кстати, gdbm надёжнее той же leveldb. Я до сих пор не столкнулся с рандомными уничтожениями файлов (от всего) в ней, что для leveldb обычное дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

173. Сообщение от Аноним (180), 05-Янв-24, 19:47   +/
В слое хранения могут быть только данные, а не логика. Логика же это код, выполняемый рядом с данными. И здесь речь идёт не о типах данных и прочих похожих фичах, а о UDF-ках. Нужны они по совершенно очевидной причине: перелопачивание данных прямо в СУБД работает быстрее аналогичной логике на строне клиента (на клиент нужно туда-сюда гонять данные). Этот подход широко используется в биг дате в виде map-reduce и прочих схемах распределённых вычислений. Для OLTP от этого тоже может быть польза на некоторых схемах баз.

Сами же дополнительные типы данных и индексы тоже помогают ускорять работу. Обычно дублирования логики не делают т.к. завязка на фичи PG больше никуда не переносима и на другой СУБД уже не получится  получить такие же ТТХ эмуляцией логики.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

174. Сообщение от Аноним (43), 05-Янв-24, 19:55   –1 +/
Не стоит демонизировать орм, это отличная штука на практике. Большинство практических задач решаются только на уровне орм, да и построитель запросов в любом случае необходим. Кроме того, он позволяет сосредоточиться на логике приложения. Просто надо уметь с ним работать. Ну и понимать ограничения (а у каждой реализации будет своя специфика).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

175. Сообщение от Аноним (180), 05-Янв-24, 19:56   +/
Не уже, а всего лишь. Типичное время вендрения чего-либо это 1-5 лет если апстрим в принципе не против
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #209

176. Сообщение от Аноним (43), 05-Янв-24, 19:59   +/
>SQLite с индексами, оптимизацией сложных запросов и оверхедом на всё это просто избыточен: сам ORM строить подобные запросы не умеет

я не знаю, что у тебя за орм, но нормальный орм всё это умеет, и, кроме того, позволяет всё настроить дополнительно, для уровня базы, при этом, у тебя остаётся уровень орм для интересных вещей, поддержка которых не реализуема эффективно в сикуль

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

177. Сообщение от Аноним (180), 05-Янв-24, 20:12   +/
> Есть простое правило, если с данными работают атомарно (не нужно читать или изменять отдельные поля внутри), то так даже эффективнее хранить в одной колонке.

Здесь принцип деления совершенно другой: в БД может быть форматная обязательная часть данных и неформатная в виде документа. Раньше были отдельные СУБД для форматных данных с чёткой схемой и специальные документные СУБД. Поле JSON в PG существует для объединения этих двух подходов  в реляционной СУБД. Таким образов в колонки по прежнему уходят форматные данные, а документ в JSON. Раньше документ приходилось хранить в виде блоба и декодировать только на клиенте. C JSON можно строить индексты по документам и работать с ним прямо из SQL. Вот и вся магия с JSON полем. Хранить обычные колонки в JSON поле не эффективно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #187

178. Сообщение от Аноним (180), 05-Янв-24, 21:02   +/
Ок, проблема понятна. Да, неприятная особенность SQLite. Только это не проблема эффективности хранения и отсутствия схемы, а проблема отсутствия ограничений по типу. Хранение тут более-менее эффетивное, но не самое оптимальное. LE или BE для СУБД вообще никакого значения не имеет, считай это особенностью кодирования. СУБД может хранить числа как угодно, хоть всё в VARINT-ах или поколоночном delta кодировании на битах. LE или BE имеет значение толлко когда есть возможность работать с данными прямо из хранилища, SQL СУБД такой фичей не обладают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

179. Сообщение от Аноним (180), 05-Янв-24, 21:07   +3 +/
ORM есть смысл использовать только когда совсем не умеешь работать с базами данных
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

180. Сообщение от Аноним (180), 05-Янв-24, 21:14   +/
Нет никакой проблемы навернуть какую-нибудь log-structured хрень на коленке на текстовых файлах в читабельном для человека виде, с транзакциями, контрольными суммами и компакшенами. От SQLite здесь требуется только хранение данных между перезапусками приложения, сами базы мелкие и все данные из них можно грузить сразу в память. Собственно потому log базы для этого отлично подходят и они просты в реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

181. Сообщение от Аноним (181), 05-Янв-24, 21:30   –1 +/
>SQLite работает. Postgres работает. MariaDB/InnoDB работает. LMDB работает. MongoDB работает

До первого хорошего кабздеца на критичных и очень дорогих карману данных. И тут-то высняется, что будь там оракел, отделались бы испугом, а тут или вообще все в хлам, или многодневное восстановление, а это лямы убытков. Оракелу-то аналогов и нет, по большому счету.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #182

182. Сообщение от Аноним (26), 05-Янв-24, 22:26   +1 +/
Ну да, точно, оракел же сам Кашпировский зарядил на неломаемость, так что он сохранит ваши данные, даже если датацентр выгорит полностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #185, #188

183. Сообщение от Аноним (26), 05-Янв-24, 22:28   +1 +/
> Ещё раз, нахрена именно оркал? SQL везде примерно одинаков. За что именно платят оркам сотни нефти за лицензии на базы? Что там такого в этой DBMS, что нет ни у кого другого?

Самые крупные суммы контрактов — соответственно, самые крупные откаты. Оно и в этой стране, и в Европе, и за океаном высоко котируется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

184. Сообщение от Антонимусс (?), 05-Янв-24, 22:33   –1 +/
> работает только в специфическом use case гугля.

Отлично работает, так что остальным остаётся только завидовать.

> вот видишь - конь-куренция! А у орацла - контора одна, и другого источника патчей у тебя нет

PG под разными предлогами отказываются принимать патчи, исправляющие реальные проблемы. По всей видимости, чтобы случайно не поломать кормящийся на этом бизнес. Конкуренция, ага.

Оракл в ноябре начали предлагать допиленный PG в качестве опции в своем клауде (OCI).

Короче, хотите нормальный PG - платите.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #216

185. Сообщение от Аноним (180), 05-Янв-24, 22:44   +/
В серверных СУБД есть репликация и это относительно стандартные сетапы. В SQLite нет ничего кроме защиты от краха ПО во время записи в файл бд
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

186. Сообщение от Антонимусс (?), 05-Янв-24, 22:58   +/
> Кому по вкусу PG - ради бога, ставьте, ОН ТОЖЕ РАБОТАЕТ. Вам гугловские патчи точно не нужны.

Например. В PG есть счётчик транзакций (XID), который постоянно увеличивается. Когда он переполняется, то вся база встаёт раком. Сбрасывается запуском Vacuum. Он тоже нагибает базу, но временно. В опенсорсной версии размер счетчика 32bit и вам нужен периодический vacuum и как следствие - даунтаймы. Во всех коммерческих форках он уже давно 64 bit (мне кажется это первое, что сразу фиксят), так что с проблемой переполнения вы просто ни когда в жизни не столкнетесь.

Таких приключений по всему PG разбросана тьма. Пока ваш проект уровня студенческой лабораторной - кушайте рекламу и пользуйтесь на здоровье опенсорсной версией. Только не воспринимайте в серьез - в продакшн придется заплатить. Причем косты будут сопоставимы с тем же Ораклом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #204

187. Сообщение от fuggy (ok), 05-Янв-24, 23:35   +/
> C JSON можно строить индексты по документам и работать с ним прямо из SQL

Я про JSON и веду речь. Можно создать индекс, но подход немного в другом. Что если нужно построить индекс по json-колонке, то скорее всего нужно селектить и джойнить, то тогда эффективней вынести её в отдельную настоящую колонку (конечно если у вас микро таблица). А если уж нужно апдейтить json-поле, то тогда это делать почти обязательно, ведь PostgreSQL пока не умеет редактировать на месте и будет копировать, например мегабайтный json, целиком. Если нужно просто: юзер json положил, юзер json целиком прочитал, то jsonb идеально подходит. На заголовки строки и колонки есть накладные расходы, и если колонок много и их не обрабатывают на SQL, то можно замерять и в некоторых случаях может оказаться что их эффективнее хранить виде jsonb. Но в коменте выше было именно иметь в виду атомарный json-объект.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

188. Сообщение от Аноним (181), 06-Янв-24, 00:43   +/
Иди хотя бы доки по оракелу почитай, а потом по постгрям всяким, и призадумайся, что такого во оракеле есть, чего нет в постгрях, и зачем вообще это нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #190

189. Сообщение от Вы забыли заполнить поле Name (?), 06-Янв-24, 00:46   +1 +/
> Все так хорошо, что его надо постоянно навязывать и писать в интернете
> проповеди о его превосходстве.

Путаешь с растом. Постгресу реклама не нужна.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

190. Сообщение от Аноним (26), 06-Янв-24, 02:08   +1 +/
Так и знал, что ничего, кроме "бла-бла-бла", от вас, маркетологов, не добиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #193

191. Сообщение от Tron is Whistling (?), 06-Янв-24, 10:29   +1 +/
Ну и как там с переиспользованием?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

192. Сообщение от Tron is Whistling (?), 06-Янв-24, 10:35   +/
А ведь да, я таки посмотрел в его on-disk format. И страницы есть, и даже free space map есть.
Вот только толку от этого нет никакого абсолютно. Как можно было умудриться со страничным форматом так залететь - сказать сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

193. Сообщение от Прохожий (??), 06-Янв-24, 12:29   +1 +/
У Oracle есть такая технология, как Flasback Database. Для огромных баз данных - очень полезная штука, если какое-нибудь обновление свалилось и надо восстановиться быстро (несколько минут) к предыдущему состоянию.
Есть разные способы доставки архивных файлов журнала регистрации транзакций (выбирается в зависимости от ценности твоих данных и быстроты сети между основной и резервной базовый данных.
Есть настраиваемые способы контроля при записи блока данных на диск.
Есть recovery manager, который битые блоки, отдельные таблицы может восстанавливать.
Есть возможность записи данных на диск мимо буферов ОС.
И так далее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #211

194. Сообщение от Прохожий (??), 06-Янв-24, 12:33   +2 +/
Проблема не только в миграции, как таковой. Проблема ещё в технологической ущербности (по сравнению с Ораклом) других СУБД такого же класса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

195. Сообщение от Прохожий (??), 06-Янв-24, 12:37   +1 +/
Ещё раз. С Ораклом тебе гораздо проще рулить базами с ценными данными. Просто иной раз на порядок проще. Потому что разработчики Оракла изначально были нацелены на Энтерпрайз решения, а не на сайтик Васяна из Мухосpанска.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

196. Сообщение от Прохожий (??), 06-Янв-24, 12:41   +1 +/
Просто других СУБД он в жизни не видел, только эту смог освоить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

197. Сообщение от Прохожий (??), 06-Янв-24, 13:13   –1 +/
Тебе шашечки или ехать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

198. Сообщение от adolfus (ok), 06-Янв-24, 17:39   +/
Два и более одновременно работающих пользователя с базой данных в любом случае требуют блокировок и сериализации доступа, а работа с двумя и более таблицами в любом случае требует ACID-транзакций.
В противном случае практически сразу базу запорете.
Не, можно использовать b однопользовательские СУБД, но придется самому реализовывать все алгоритмы "читатели-писатели", семафоры, мьютексы и и прочие сериализационные кунштюки. Но только, если язык вашей субд это позволяет. Инасе придется все операторы вашей СУБД обернуть в функции си или сикрос-крос, чтобы задействовать многопользовательские механизмы posix.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #205

199. Сообщение от Аноним (199), 06-Янв-24, 18:27   –2 +/
Мусор даже не поддерживает пул-потоков из коробки в отличии от МашаДБ.
md5 аутентификация? Вы серьёзно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #217

200. Сообщение от Rollo99email (ok), 07-Янв-24, 21:28   +/
Вопрос к знатокам Postgre.
Есть ли инструмент для восстановления одной конкретной БД на сервере на произвольный момент времени из бекапа без остановки всего инстанса?
Без развлекухи с ручным поднятием временного инстанса PG, восстановления и выгрузки\загрузки дампа.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #202

201. Сообщение от Аноним (201), 08-Янв-24, 23:16   +/
и на нормальном ЯП
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

202. Сообщение от Аноним (205), 09-Янв-24, 00:50   +/
Ты ща спросил примерно такую фигню: "А можно открыть книгу "Каштанка", пролистать до середины и на следующей странице чтоб были "Мцыри"?". Ну вот как ты без остановки сменишь базу? Вернее, что тебе даст "работающий инстанс", если ему всё равно придётся сбросить ВСЁ и загрузить бэкап как АБСОЛЮТНО НОВУЮ базу? Ты ничего не выйграешь, что с остановкой, что без.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #212

204. Сообщение от Аноним (205), 09-Янв-24, 00:56   +/
Увы, долго постгрес не использовал вообще - у меня пока пет-проекты на нём. Но это не отменяет моих слов - у БОЛЬШИХ компаний проблемы вообще несопоставимы с очередным наколенным "Склад-33". А если счётчик транзакций можно перезапустить остановкой сервера, то скорее всего так и будет. Ну то есть для большинства компаний Постгрес - вполне работающая вещь. На крайняк - возьмут MS SQL, не сильно дорогая вещь (вот я с ним во весь рост писал!).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

205. Сообщение от Аноним (205), 09-Янв-24, 01:24   +/
Ну не, не всё так сложно. Вернее, некотрые сложности РСУБД можно избежать.
Классические реляшки опираются на то, что в любой момент есть несколько клиентов, каждый из которых может запустить любую операцию CRUD и каждая операция не должна тормозить. Поэтому приходится выворачиваться на полную катушку со всеми подкапотными хитростями.

Для "маленького офиса"(SOHO) мы можем допустить:

1. Клиенты пишут в базу редко и быстро (создание документов, какие-то мелкие логи). Что позволяет блокировать таблицу ДЛЯ ВСЕХ операций без дополнительных трюков. Лок, запись, анлок.
2. Соотв. чтение может ну совсем иногда подтормаживать, но в целом работает быстро - нет никаких "слепков базы", "транзакций чтения" и т.п. Что видит один клиент, видят все.
3. Подразумеваем, что мы работаем в стабильной среде - т.е. есть электричество и никто в середине записи не дёрнет рубильник. Собственно, так и работает ЛЮБОЙ современный сервер - как минимум на UPS, как максимум - на генераторе.

Зная всё это, можно сильно упростить все операции с таблицами и трансформировать работу с реляционной базой - таблицы останутся реляционными, но метод работы с ними будет как у FoxPro - "мануальный": "Считать все записи таблицы", "пройтись по записям, сохранить в переменной все зарплаты", "взять запись, найти записи в другой таблице, зависящие от этой, удалить".

Это просто как пример операций, НО(!) сложные запросы перестанут быть "сложнодекларативными" - они станут ИМПЕРАТИВНЫМИ (что сильно упростит код программиста для алгоритмически тривиальных задач а-ля "найти все города, где люди выше среднего и в музыке любят рок").

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198

206. Сообщение от Аноним (206), 09-Янв-24, 08:06   +/
Postgres Pro Enterprise Manager уже кто-нибудь использует?
Ответить | Правка | Наверх | Cообщить модератору

207. Сообщение от Аноним (207), 09-Янв-24, 08:45   +/
А майкософт уже подключился к "разработке" Postgres ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #208

208. Сообщение от dmrjan (?), 09-Янв-24, 14:39   +/
Microsoft уже давно сказал, что PostgreSQL Pro Enterprise конкурентоспособная база данных. С учетом того, что появился Postgres Pro Enterprise Manager, как аналог management studio, то мелкомягкие точно не пропустят этот момент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

209. Сообщение от нах. (?), 09-Янв-24, 16:40   +/
> Не уже, а всего лишь. Типичное время вендрения чего-либо это 1-5 лет
> если апстрим в принципе не против

"так это наверное нескоро" (с)

(ну в смысле можно считать что скорее нет чем есть - а там либо ишак, либо падишах, либо сам Ходжа...)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

210. Сообщение от Аноним (210), 09-Янв-24, 17:25   +/
Пока есть такие "специалисты", у нас будет работа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #219

211. Сообщение от specter (ok), 09-Янв-24, 18:17   +/
Это которая PITR в PG?
Это которые https://www.postgresql.org/docs/11/different-replication-sol... ?
Это не задача БД
pg_probackup?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #214

212. Сообщение от PnD (??), 10-Янв-24, 12:41   +/
Вопрос в целом таки по делу. Будь WAL свой для каждой БД, такой фокус вполне мог бы прокатить "в лоб".
Но у постгри единое состояние для всех БД одного инстанса. И это, в целом, не самое дурное решение (ресурсы-то общие).

Я бы посмотрел в сторону новых механизмов репликации. Там вроде появились логи транзакций. И из них можно вытащить то что M$ продаёт последние 20+ лет. Полный бэкап отдельной БД, плюс инкрементный (транзакции с момента полного бэкапа).

* Возможно даже что у кого-то такое есть готовое. За денюжку.
Понятно, ценой производительности/места на СХД, в силу архитектурных нюансов.

** В моих краях N лет назад приняли решение "не выпускать новые проекты под Oracle DB".
Старые мигрировать дурных не нашлось. А так, можно постепенно допиливать под свои кейсы. И делать код с учётом известных особенностей постгри. А не "сделайте мне (на шару) 1:1 как в энтерпрайзе за вагон денег".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

214. Сообщение от Прохожий (??), 11-Янв-24, 00:25   +/
> Это которая PITR в PG?

Это гораздо, на порядки, быстрее, чем PITR. Почему? Потому что у тебя нет необходимости восстанавливать всю БД целиком, а потом накатывать логи до необходимого момента в прошлом. Оракл откатывается по флешбэк-логам. Притом делает это очень-очень быстро. Для террабайтной БД на обычном дисковом массиве такой откат занимает считанные минуты (в зависимости от того, сколько логов после точки восстановления ты успел нагерерить).

> Это которые https://www.postgresql.org/docs/11/different-replication-sol... ?

Нет. Это три основных режима накатки логов на стендбай (физический, а есть ещё логический): синхронный, асинхронный, запись прямо в логи стендбая.

>> Есть настраиваемые способы контроля при записи блока данных на диск.
>Это не задача БД

Ну конечно, когда этого нет в любимой СУБД - сразу становится "не нужной фичей". :) PG так не умеет, от слова "совсем". Оракл - умеет. И это довольно важная фича, если ты не особо доверяешь своему железу, которое с дисками работает.

> pg_probackup

Он не умеет восстанавливать битые блоки. И это сторонняя программа. RMAN - стандартный инструмент для управления бекапами у Оракла. И он более фичастый.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

215. Сообщение от bOOster (ok), 11-Янв-24, 06:13   +/
- "Упрямство - достоинство ослов"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

216. Сообщение от bOOster (ok), 11-Янв-24, 06:25   +/
Ага, отказываются принимать патчи от таких знатоков как ты? Лечашие одну проблему и создающие десяток других? Нуну..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

217. Сообщение от bOOster (ok), 11-Янв-24, 09:08   +/
Серьезно, мозгов тебе не хватило до kerberos авторизации/аутентификации?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

219. Сообщение от пох. (?), 16-Янв-24, 09:54   +/
> Пока есть такие "специалисты", у нас будет работа.

мляя, а НОРМАЛЬНОЙ работы - что, уже совсем нет?!

Вот всю жизнь мечтал выносить горшки за альтернативно-одаренными (прямо в офисе куда их по квотам набирают)


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210


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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру