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

"Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL"	+/–
Сообщение от opennews (??), 06-Дек-21, 11:21
Штайнар Гундерсон (Steinar H. Gunderson), один из авторов библиотеки сжатия Snappy и участник разработки IPv6, объявил о возвращении в компанию Google, в которой в своё время занимался разработкой сервисов поиска по изображениям и offline-картами, но теперь будет вовлечён в разработку браузера Chrome. До этого Штайнар в течение пяти лет работал в Oracle над модернизацией оптимизатора СУБД MySQL. Заметка Штайнара примечательна критическим отношением к перспективам MySQL и рекомендацией переходить на PostgreSQL... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56287
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 06-Дек-21, 11:21	–1 +/–
всегда использовал слоника заместо вот этого вот детища оракула
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #18, #51, #117

2. Сообщение от AleksK (ok), 06-Дек-21, 11:22	+7 +/–
Вот кстати тоже не понимаю зачем нужен MySQL если есть Postgres, который уделывает его по всем параметрам.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #6, #42, #87, #116

3. Сообщение от Аноним (3), 06-Дек-21, 11:22	+4 +/–
> рекомендовал использовать PostgreSQL дак я уже
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

4. Сообщение от _hide_ (ok), 06-Дек-21, 11:25	+21 +/–
>>> всегда использовал слоника Тот, кто так говорит, явно не мог его использовать 12+ лет назад. Значит использует лет 5 от силы, т.е. для проектов однодневок. Возможно в этом и причины их мимолетности. >>> детища оракула Ну это полностью подтверждает сказанное выше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #14, #80, #90, #126, #157, #222

5. Сообщение от _hide_ (ok), 06-Дек-21, 11:27	+7 +/–
>>> уделывает его По каким параметрам? >>> по всем А мне казалось, что применение PG -- это очень взвешенное и обоснованное решение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от funny.falcon (?), 06-Дек-21, 11:30	+8 +/–
Не по всем. Я, как любитель PostgreSQL, ответственно заявляю. Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё актуальны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #11, #34, #121, #147

8. Сообщение от Перастерос (ok), 06-Дек-21, 11:35	+7 +/–
Сейчас будет холивар? Я за Postgres! )
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

10. Сообщение от flexagoon (ok), 06-Дек-21, 11:40	–13 +/–
> MySQL сильно устарел и не эффективен, при том, что большинство пользователей и разработчиков считают, что всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёд Они тут слово "My" нечаянно перед "SQL" добавили
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #169

11. Сообщение от AleksK (ok), 06-Дек-21, 11:40	–3 +/–
> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё > актуальны. Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #17, #204

12. Сообщение от Аноним (12), 06-Дек-21, 11:42	–17 +/–
Использовал и то и другое, особой разницы не заметил. Для малых и средних сайтов MySQL - идеальное решение, поскольку там лучше дока и больше туторов. А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами и оптимизациями банально не потянет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #16, #33, #148

13. Сообщение от Аноним (-), 06-Дек-21, 11:48	+3 +/–
Ну всё, мария не торт, мускуль не торт, постгрес не торт, и раст нас не спасёт, потому что там тоже все paзocpaлиcь.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #31, #41

14. Сообщение от Аноним (1), 06-Дек-21, 11:51	+9 +/–
с 2011, мистер Холмс, сэр
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

15. Сообщение от Аноним (15), 06-Дек-21, 11:52	+5 +/–
Рукожоп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 06-Дек-21, 11:55	+6 +/–
Не знаю чем там сильно отличаются туториалы для малых и средних сайтов, так как для малых и средних сайтов база всё равно считается детской по структуре. А вот для более серьёзных проектов (веб/десктоп, АРМ, и тд) всё таки более гибкая в проектировании PostgreSQL я считаю. Логику делать очень удобно. И как раз таки нормальная дока по нему в целом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

17. Сообщение от Gemorroj (ok), 06-Дек-21, 11:55	+/–
миграция на более новые версии у mysql на порядок проще. мультимастер (galera в mysql). некоторый синтаксический сахар (работа с enum, например).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #21, #40, #47

18. Сообщение от Ян Злобин (ok), 06-Дек-21, 11:57	+1 +/–
>  всегда использовал слоника заместо вот этого вот детища оракула Ничего вы, батенька, не понимаете в залепухах для прачечных!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

19. Сообщение от Простоник (ok), 06-Дек-21, 11:58	+/–
MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #115, #134, #224

20. Сообщение от kai3341 (ok), 06-Дек-21, 12:00	+5 +/–
Блин. InnoDB интересен своей ораклиной структурой данных -- кластерный первичный ключ. Реализация MVCC не гадит себе под ноги, необходимость богомерзкого autovacuum отсутствует. Когда БД корректно остановлена, она не содержит мусора. InnoDB -- это топовый OLTP движок Претензии есть. Реализация fulltext очень грустная, не поддерживает партиционирования. То есть если вы индексируете, например, новости, которые есть временной ряд -- поиск с указанием временных рамок будет крайне грустненьким PS: У постгреса другие сильные стороны. Например, бесплатный rollback
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57, #58, #64, #68

21. Сообщение от AleksK (ok), 06-Дек-21, 12:02	–9 +/–
Когда работаешь с ORM вообще пофиг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #22, #26

22. Сообщение от x3who (?), 06-Дек-21, 12:06	+2 +/–
ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #23

23. Сообщение от AleksK (ok), 06-Дек-21, 12:13	–8 +/–
> ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят. Вот именно, я работаю со своей объектной моделью, мне пофиг на то что там происходит под капотом. Но с Posgtres для меня все работает быстрее, и админить его ИМХО проще и удобнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #137

24. Сообщение от Аноним (1), 06-Дек-21, 12:13	+1 +/–
так вы женщина??
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #54

25. Сообщение от Аноним (33), 06-Дек-21, 12:17	–1 +/–
Местные Аноноимы опускают MySQL уже 20-ый год. Но только сейчас до одного из разработчиков MySQL дошло что он занимается фигнёй.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #45

26. Сообщение от keydon (ok), 06-Дек-21, 12:19	+1 +/–
Когда работаешь с patroni - тоже
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

27. Сообщение от devkornev (ok), 06-Дек-21, 12:20	+1 +/–
С новыми проектами - ок, выбор за Postgres. Но что делать, где уже MySQL. Обновление с 5 на 8 выливается в существенное замедление.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

28. Сообщение от Кондратий Карлович (?), 06-Дек-21, 12:21	–1 +/–
А как там у постгресс с вакуумом  ??
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #66, #221

29. Сообщение от Rev (?), 06-Дек-21, 12:21	+3 +/–
> там тоже все paзocpaлиcь Кто "все"? Модераторы CoC? Ах, увольте...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #81

30. Сообщение от Аноним (33), 06-Дек-21, 12:24	+3 +/–
Ты ведь сейчас вордпресс имел ввиде и что УГ, да? И правильно сделал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #38

31. Сообщение от Аноним (33), 06-Дек-21, 12:25	+1 +/–
Всегда остаётся Хаскель!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

32. Сообщение от анонимчик (?), 06-Дек-21, 12:25	+3 +/–
он идет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

33. Сообщение от Аноним (33), 06-Дек-21, 12:26	+/–
Вывод ты делаешь малые и средние сайты. Больше из твоего комментария нечего почерпнуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

34. Сообщение от Cykooz (ok), 06-Дек-21, 12:27	+/–
Насколько помню они вернулись не в совсем обычный MySQL, а в какую-то свою кастомизацию, с помощью которой они из MySQL сделали Key-Value базу данных. Вероятно тогда это было легче сделать в MySQL, т.к. там есть поддержка разных движков для хранения данных. В Postgres она появилась только недавно. Поэтому не совсем корректно говорить, что они вернулись именно в MySQL, т.к. они фактически перешли на совершенно другой тип базы данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #69

35. Сообщение от Аноним (-), 06-Дек-21, 12:32	+1 +/–
> всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёд Ну ушли себе и ушли, это их проблемы.
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Аноним (-), 06-Дек-21, 12:34	+1 +/–
Если копры его забросят - получится отличный и стабильный продукт. Надеемся что не начнут хотеть переписать на раст или что-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #37

37. Сообщение от Аноним (37), 06-Дек-21, 12:38	+/–
Стагнация ещё ни один проект до добра не доводила.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #46, #104

38. Сообщение от Простоник (ok), 06-Дек-21, 12:39	–4 +/–
(Зевая) Я не знаю что там хранит вордпресс и в каком виде, но хранить в подобной базе большое количество таблиц особенно со сложной структурой и сложными запросами я бы не стал. А так пяток таблиц для блога подойдёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

39. Сообщение от An (??), 06-Дек-21, 12:50	–1 +/–
А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил на себе адсенс гугла, метрику и директ яндекса. А? Это говорит о том, что вы, господа - рукожопы. И не умеете готовить мускул.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43, #48, #49, #61, #67

40. Сообщение от Аноним (40), 06-Дек-21, 12:55	+/–
>более новые версии а есть менее новые? Ну или хотя бы более лучшие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

41. Сообщение от Аноним (41), 06-Дек-21, 12:57	–2 +/–
Вся надежда на Монго
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #53

42. Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:06	–3 +/–
Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо больше) А так в нём нет ни unsigned, не int1 и int3, и даже ALTER TABLE ... ADD ... AFTER ...; нету. Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка тоже нету! Ох уж эти мамкины уделыватели по всем фронтам...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #56, #122, #182

43. Сообщение от Аноним (41), 06-Дек-21, 13:10	+4 +/–
На маленьком проекте использовал гугл адсенс. Подключил скрипт JS и всё. Базу не использовал вообще. Путь к скрипту лежал в файлике. Значит можно мускуль заменить на файлик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

44. Сообщение от Аноним (44), 06-Дек-21, 13:11	+1 +/–
А я никогда мускуль и не использовал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #234

45. Сообщение от th3m3 (ok), 06-Дек-21, 13:11	+5 +/–
Наконец-то мы были услышаны! Ждём осознания в станах Вордпресса, пехепешников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #55, #74

46. Сообщение от Аноним (-), 06-Дек-21, 13:14	+1 +/–
Пральна, раздать все копрам, и сосать лапу. Иначе же стогнация, нелицензионность и прочая протухаемость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

47. Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:15	–1 +/–
> (работа с enum, например). enum в постгресе одна из немногих вещей которая мне понравилась. В MariaDB я его никогда не использую, так как есть более эффективный tinyint unsigned, а соответствия можно в php массивом в константе класса сохранить. Но в посгресе нет ни tinyint ни unsigned но можно определить 1 раз enum и вставлять его в 2 и более таблицы, а если нужно модифицировать то делается это 1 раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

48. Сообщение от Аноним (48), 06-Дек-21, 13:15	+/–
Про MySQL в Google Adsense - это миф, никогда он там не использовался. Вы видимо с Facebook путайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

49. Сообщение от Аноним (33), 06-Дек-21, 13:19	+/–
В mail.ru используют джангу вместе с MySQL и им норм. Но это совершенно не значит что так надо делать всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

50. Сообщение от Аноним (33), 06-Дек-21, 13:22	+/–
Масштабироваться причем вертикально. Горизонтально не каждый сможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

51. Сообщение от Аноним (51), 06-Дек-21, 13:25	+9 +/–
Зелёного?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

52. Сообщение от Аноним (-), 06-Дек-21, 13:27	–7 +/–
лишь бы не брать монгу
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59

53. Сообщение от Аноним (-), 06-Дек-21, 13:30	+2 +/–
..умерла в далеком 11м году
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #73

54. Сообщение от Аноним (-), 06-Дек-21, 13:31	+1 +/–
у тащмайора спроси, тут поди процентов 80
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #168

55. Сообщение от Аноним (55), 06-Дек-21, 13:33	+1 +/–
Не ждите - у них там религиозный культ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

56. Сообщение от Наме (?), 06-Дек-21, 13:34	–4 +/–
> Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо > больше) > А так в нём нет ни unsigned, не int1 и int3, и > даже ALTER TABLE ... ADD ... AFTER ...; нету. > Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка > тоже нету! > Ох уж эти мамкины уделыватели по всем фронтам... Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), а Дельфин по умолчанию ISAM (транзакций и WAL-а нет, но бывают задачи где это всё лишняя нагрузка). Это как ткацкий станок сравнивать с вязальными спицами -- каждый хорош для своих задач.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #62, #85

57. Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:34	+/–
> Реализация fulltext очень грустная Ну так если нужно нормальный, то для этого Sphinx есть. А то что есть это просто что бы было кому лень со сфинксом заморачиваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

58. Сообщение от Наме (?), 06-Дек-21, 13:46	+1 +/–
> Блин. InnoDB интересен своей ораклиной структурой данных -- кластерный первичный ключ. > Реализация MVCC не гадит себе под ноги, необходимость богомерзкого autovacuum отсутствует. > Когда БД корректно остановлена, она не содержит мусора. InnoDB -- это > топовый OLTP движок > Претензии есть. Реализация fulltext очень грустная, не поддерживает партиционирования. > То есть если вы индексируете, например, новости, которые есть временной ряд > -- поиск с указанием временных рамок будет крайне грустненьким > PS: У постгреса другие сильные стороны. Например, бесплатный rollback Попутал ты всё. Какой "кластерный первичный ключ"? Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча, хотя с 12-той версии появилась возможность реализовывать индексно-организованными таблицами (но редко кто так делает). Какая разница куда "гадим" MVCC? Когда нет необходимости каждый раз плодить UNDO-данные и таскать их из одного ТП в другое это банально быстрее, но больше места жрёт в локальной перспективе времени. Тут уж надо выбирать, что ценнее пространство или время ЦП и память. В чём богомерзкость вакуума? При адекватной настройке всё просто работает. Проблемы возникают, когда в одном кластере много БД и в них сильно разные по длительности транзакции -- 31-однобитного счётчика банально начинает не хватать. Ну так это нужно учитывать при развёртывании. Инно хорошая академическая лабораторная работа, к проду не пригодная по ряду причин, вроде того, что вектор UNDO не попадает в WAL, что при краше приводит к развалу БД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #75, #86, #159

59. Сообщение от Аноним (-), 06-Дек-21, 13:47	+2 +/–
Действительно, когда нужен скуль почему же не взять монгу, хмм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

60. Сообщение от Наме (?), 06-Дек-21, 13:47	–2 +/–
Совет в духе "переходите с кефира на джек дениэлс".
Ответить | Правка | Наверх | Cообщить модератору

61. Сообщение от Наме (?), 06-Дек-21, 13:49	–2 +/–
> А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил > на себе адсенс гугла, метрику и директ яндекса. А? Это говорит > о том, что вы, господа - рукожопы. И не умеете готовить > мускул. Вряд ли. ISAM хорош, когда надо много писать в хвост и не нужны транзакции. Например, в какой-нибудь системе не слишком ответственного логирования, где источник сообщений сам имеет надёжное хранилище.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #130

62. Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:50	–2 +/–
> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), Вы не поверите, InnoDB тоже! > а Дельфин по умолчанию ISAM MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где нужна быстрая вставка можно и MyISAM использовать в той же самой БД!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #65

63. Сообщение от Аноним (63), 06-Дек-21, 13:51	–2 +/–
Дык мускуль и задуман как бесплатная поделка для студентов. Никто никогда и не говорил, что он пригоден для коммерческих продуктов. Так что я не знаю, кого он там пугает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78

64. Сообщение от Аноним (64), 06-Дек-21, 13:58	+/–
> необходимость богомерзкого autovacuum отсутствует. Документация с тобой не согласна: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #184

65. Сообщение от Наме (?), 06-Дек-21, 14:01	–2 +/–
>> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), > Вы не поверите, InnoDB тоже! >> а Дельфин по умолчанию ISAM > MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где > нужна быстрая вставка можно и MyISAM использовать в той же самой > БД! Это под вендой. Но Инно тоже Слону не конкурент. Совершенно разного масштаба явления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #70

66. Сообщение от Аноним (64), 06-Дек-21, 14:01	+/–
А как у MySql с optimize table?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #131, #132

67. Сообщение от Аноним (67), 06-Дек-21, 14:08	+1 +/–
+1 Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост. Или делать шардинг. Все что касается административной части то у слоника все печально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #82

68. Сообщение от Аноним (68), 06-Дек-21, 14:18	+1 +/–
> необходимость богомерзкого autovacuum отсутствует Богомерзкое - это писать логи. А автовакуум это красота.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #237

69. Сообщение от funny.falcon (?), 06-Дек-21, 14:19	+/–
Нет. Key-value у них - это слой абстракции сверху, а не движок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #77

70. Сообщение от funny.falcon (?), 06-Дек-21, 14:22	+1 +/–
Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #76

71. Сообщение от ыы (?), 06-Дек-21, 14:22	–1 +/–
> не выделяет должных ресурсов, что мешает поддержанию его в виде конкурентоспособного продукта. Опенсорс в полный рост... А как же разработка сообществом? Где миллион волонтеров пишущих код оптимизатора?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #97, #150

73. Сообщение от funny.falcon (?), 06-Дек-21, 14:28	–1 +/–
Очень зря. MongoDB вполне себе надёжная и удобная в эксплуатации база в наши дни. Я имею в виду эксплуатацию с точки зрения администрирования. Правда, консистентный бэкап шардированного кластера сделали платной фичей. Его можно повторить руками, но минимум несколько месяцев интенсивной разработки обойдётся. Но у кого он вообще есть - бесплатный консистентный бэкап шардированного кластера? Знаю, у TiDB. У кого ещё?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #92

74. Сообщение от 123 (??), 06-Дек-21, 14:29	+/–
В станах "Вордпресса" давно предлагают использовать MariaDB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

75. Сообщение от funny.falcon (?), 06-Дек-21, 14:31	+/–
А можно ссылочки на развал БД при краше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #96

76. Сообщение от Ilya Indigo (ok), 06-Дек-21, 14:33	–1 +/–
> Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения. Да уже по первому комментарию и так понятно что аноним совершенно не понимает о чём пишет, а когда его аргументы мною разбиты пишет снова глупость, не понятно зачем вообще упоминая оффтопик, и просит просто поверить ему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #93

77. Сообщение от Cykooz (ok), 06-Дек-21, 14:35	+/–
> Нет. Key-value у них - это слой абстракции сверху, а не движок. А, ну да. Но тем не менее они сделали "костыль" поверх MySQL, т.к. именно его движок хорошо показал себя с этим "костылём". С тем же успехом они могли взять готовую Key-Value базу, если бы была в тот момент подходящая под требования. Поэтому не очень корректно приводить пример Uber-а, т.к. они MySQL использовали довольно специфично. Примерно как сравнивать Postgres с Redis.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

78. Сообщение от ыы (?), 06-Дек-21, 14:41	+/–
очень любопытная мысль... не хотите ее развить? Расскажите нам для чего был задуман PHP, Линукс, автомобиль, колесо...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #89, #208

80. Сообщение от проект однодневка (?), 06-Дек-21, 14:49	–5 +/–
> для проектов однодневок Я аж в голос с этого клоуна!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

81. Сообщение от topin89 (ok), 06-Дек-21, 14:51	+2 +/–
Если бы всё было так просто. Один из ключевых разработчиков забросил Rust Wasm, но активно отказывался передавать управление другим ключевым разработчикам после множества просьб. Пользуясь полномочиями ключевого разраба, он активно банил неугодных порой без причин. Да и сам оказался в составе core team, потому что знакомый протащил. До этого работал в npm, где пытался турнуть некоего Рода Вагга, но не прокатило, и турнули его самого. Добавим к этому активную SJW-позицию на всё про всё. Высказывание "убить всех мужиков" и было причиной для бана, вот только у модера нет прав банить. Модераторский состав, с другой стороны, состоит преимущественно из прикладников на rust. В частности, инициатором бойкота выступил не непонятный SJW'шник, а автор ripgrep. Разработчика зовут Эшли Уильямс, подробности тут: https://news.ycombinator.com/item?id=28515306 Так что всё гораздо хуже, чем SJW-модеров уволили. Они там уже в составе разрабов. Грустно, надеюсь, таки турнут эту Эшли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #113

82. Сообщение от Наме (?), 06-Дек-21, 14:53	–1 +/–
> +1 > Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост. > Или делать шардинг. > Все что касается административной части то у слоника все печально. Ну Слоника со всем всё прекрасно. Ещё бы кластеризацию запилили и вообще было бы прекрасно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #84, #100

84. Сообщение от Аноним (67), 06-Дек-21, 15:02	+/–
Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без даунтайма
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #99

85. Сообщение от vitalif (ok), 06-Дек-21, 15:18	+4 +/–
Под какой виндой, что ты несёшь? Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #94, #95, #103, #250

86. Сообщение от penetrator (?), 06-Дек-21, 15:24	–1 +/–
в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень очень давно (задолго до появления самого Azure)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #98

87. Сообщение от minonA (?), 06-Дек-21, 15:27	+/–
Так, на вскидку, а есть ли в PostgreSQL аналог MEMORY таблицы? Вообще проблема оптимизатора MySQL преувеличена. Да, в Postgres он умнее. Но и в MySQL можно добиться схожих результатов немного подкрутив. А если говорить о простых запросах, что наиболее частый юзер-кейс, MySQL вообще ничем не хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #102

88. Сообщение от minonA (?), 06-Дек-21, 15:30	–1 +/–
А всем ли нужен мощный оптимизатор запросов?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #91, #151

89. Сообщение от Аноним (89), 06-Дек-21, 15:31	+/–
Пусть с себя начнет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

90. Сообщение от лютый жабби__ (?), 06-Дек-21, 15:31	–5 +/–
>Тот, кто так говорит, явно не мог его использовать 12+ лет назад бред, помню, даже в 2000-м году делал пару поделок на постгресе и уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых руках, а по фичам даже 21 года назад постгрес был лучше. хотя для 2021 оба мусор, тк монга рулит )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #106, #165

91. Сообщение от Простоник (ok), 06-Дек-21, 15:53	+/–
Хороший вопрос. Ответ зависит от того, сколько этот оптимизатор будет стоить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

92. Сообщение от лютый жабби__ (?), 06-Дек-21, 15:54	–1 +/–
>Правда, консистентный бэкап шардированного кластера сделали платной фичей первая же ссылка https://github.com/Percona-Lab/mongodb_consistent_backup сам не использовал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

93. Сообщение от Наме (?), 06-Дек-21, 15:57	–11 +/–
Ильюша, ты пишешь на пэхэпэ. Эти всё сказано о твоим интеллектуальных способностях и общей профессиональной эрудии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #166

94. Сообщение от Наме (?), 06-Дек-21, 15:59	–1 +/–
> Под какой виндой, что ты несёшь? > Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, > причём что важно - там нет грёбаного вакуума) Практически везде. Просто в силу того, что ISAM для многих задач достаточен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

95. Сообщение от Наме (?), 06-Дек-21, 16:05	+/–
> Под какой виндой, что ты несёшь? > Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, > причём что важно - там нет грёбаного вакуума) Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #185

96. Сообщение от Наме (?), 06-Дек-21, 16:10	–2 +/–
> А можно ссылочки на развал БД при краше? Разверни. Запусти длительную транзакцию, не завершая её выруби питание. Т.к. данные UNDO скорее всего в полном объёме не попадут в журнал, то при обратном проигрывании при восстановлении получить несогласованную БД. Тут должны, конечно, звёзды сойтись. Чтобы грязные блоки уже попали на диск, но при этом вектор UNDO ещё нет. Но во "взрослых" СУБД это принципиально невозможно, а в Инно вполне под рабочей нагрузкой. Хотя это практически, объективно говоря, маловероятно, но при случае проблем при восстановлении добавит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #119, #133, #155, #156

97. Сообщение от Аноним (-), 06-Дек-21, 16:12	+/–
Не хотят Орацлу земные поклоны отбивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

98. Сообщение от Наме (?), 06-Дек-21, 16:12	–1 +/–
> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень > очень давно (задолго до появления самого Azure) Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #101

99. Сообщение от Наме (?), 06-Дек-21, 16:16	–2 +/–
> Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без > даунтайма А в чём сложность? Ну не RAC, конечно, но вполне можно довести до приемлемого уровня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #129

100. Сообщение от Alexander (ok), 06-Дек-21, 16:41	+/–
уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #112

101. Сообщение от penetrator (?), 06-Дек-21, 16:45	–1 +/–
>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень >> очень давно (задолго до появления самого Azure) > Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское. некластерный, heap или как хочешь еще, и он там есть и есть очень давно PK в MSSQL может быть 2 типов с пробуждением
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #105, #107, #108

102. Сообщение от AleksK (ok), 06-Дек-21, 16:45	–1 +/–
Я сужу по тому как работал мой проект на рельсах. Загрузка базы в проект из yaml ну просто в разы быстрее при использовании postgres, да и отзывчивость в общем получше. Я не проводил специальных тестов просто общие впечатления от работы на одном и на другом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #135

103. Сообщение от Аноним (103), 06-Дек-21, 16:48	+2 +/–
Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это те же яйца даже не в профиль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #109, #136

104. Сообщение от Аноним (103), 06-Дек-21, 16:56	+/–
Ой, да ладно! Составит компанию Firebird, делов-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

105. Сообщение от Наме (?), 06-Дек-21, 16:59	–1 +/–
>>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень >>> очень давно (задолго до появления самого Azure) >> Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское. > некластерный, heap или как хочешь еще, и он там есть и есть > очень давно > PK в MSSQL может быть 2 типов > с пробуждением Heap это, пардон, куча. Т.е. когда данные хранятся вообще вне всякой упорядоченной структуры, а просто страницы в цепочку выделяются по IAM. В Сибэйсе хренелион лет назад решили, что коль уникальный индекс практически всегда создаётся, то логично в структуре этого индекса хранить и все прочие данные, которые не входят в индексный ключ, а не отдельно кучу и отдельно би-три с листами с индексным ключом. Ну и сделали такою смесь верблюда с носорогом -- сверху служебные структуры би-три, а на листах все данные. Ну вот, эту хрень и назвали кластерным индексом. В принципе, логичное решение, но проблема в том, что одного индекса в типичных условиях никогда не бывает достаточно, а хранение всех данных в структуре какого-то одного индекса зачастую приводит к смещению статистик распределения со всеми печальными последствиями. Поэтому тот же Оракл такого не делал. Я уж не помню, когда они ввели что-то подобное, по-моему, с 12-той версии. В Слоне тоже такого не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #152

106. Сообщение от _hide_ (ok), 06-Дек-21, 17:00	+5 +/–
> бред, помню, даже в 2000-м году делал пару поделок на постгресе и > уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых > руках, а по фичам даже 21 года назад постгрес был лучше. Всё зависит от того, чем Вы занимаетесь. При обновлении 10-15 ГБ с ПГ Вы упираетесь в IO и уже можете наращивать скорость только за линейно, у MySQL имеется возможность такие проблемы отсрочить. > хотя для 2021 оба мусор, тк монга рулит ) Вот всегда хотел спросить, сколько полезных проектов на Монге есть сейчас, старше 5-8 лет? Просто мой поиск мне даёт очень интересные результаты. Ну и википедия подсказывает, что Монга это... Ну в общем, не база данных, хотя может заменить некоторые простые её функции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #164

107. Сообщение от Наме (?), 06-Дек-21, 17:01	–1 +/–
> PK в MSSQL может быть 2 типов Как бы, PK это не индекс, а Constrain -- ограничение первичного ключа. Который реализуется, под капотом, созданием уникального кластерного уже Индекса, если явно не заказать создавать не кластерный индекс, а дополнительный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

108. Сообщение от Наме (?), 06-Дек-21, 17:07	–1 +/–
> некластерный, heap или как хочешь еще, и он там есть и есть > очень давно > PK в MSSQL может быть 2 типов Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK же (Primary Key) это одно из видов Ограничений, которое реализуется либо тем, что все данные отношения помещаются в структуру индекса, либо тем, что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой на листах хранятся данные индексного ключа и ссылки на страницы кучи, где хранится оригинальная индексируемая строка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #110

109. Сообщение от Наме (?), 06-Дек-21, 17:13	+/–
> Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это > те же яйца даже не в профиль. Нет, это и близко не одни и те же "яйца". Одна чистит БД от призраков и освобождает счётчик транзакций (изменений), другая проводит пересортировку таблиц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #188, #192

110. Сообщение от Наме (?), 06-Дек-21, 17:18	+/–
> Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в > куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK > же (Primary Key) это одно из видов Ограничений, которое реализуется либо > тем, что все данные отношения помещаются в структуру индекса, либо тем, > что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой > на листах хранятся данные индексного ключа и ссылки на страницы кучи, > где хранится оригинальная индексируемая строка. Хотя, малыши, я тут несколько ошибся. Когда заказываешь PK к существующему уже отношению, в котором есть данные, то данные из кучи перемещаются в это би-три, а исходная куча удаляется, если же заказать PK при создании отношения, то и не будет создаваться, а сразу будет создано би-три, в который данные отношения и будут писаться. Если же создать PK и явно указать, что ограничение должно реализоваться доп. индексом, то будет к куче создан доп. индекс в виде би-три. Вот и всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

111. Сообщение от Аноним (111), 06-Дек-21, 17:27	+/–
"но в общем виде работа оценивается как доведение его до уровня технологий начала 2000-х годов" И вот что ему не нравится. Технологию (пусть и старую) ДОВОДЯТ ДО УМА! А что постгресс? Конфетка уже?
Ответить | Правка | Наверх | Cообщить модератору

112. Сообщение от Наме (?), 06-Дек-21, 17:37	+/–
> уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/ Ну это Мария. А это всё тот же ISAM, только навороченный. Но я не пробовал, ничего сказать не могу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #123, #239

113. Сообщение от Kuromi (ok), 06-Дек-21, 17:56	+/–
Отличная ссылочка. Читается на одном дыхании как один большой анекдот. Только это все реальность. Хотя если честно я не понимаю что мешает Rust Core Team обратиться к админам гитхаба и попросить передать им права, в конце концов речь идет не о группе анонимов из даркнета, а официально существующей организации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

114. Сообщение от bsdun (?), 06-Дек-21, 18:42	+/–
А что никто не говорит про Group Replication в MySQL из каропки, которой в PostgreSQL и в помине нет. Чёт не догоняю чем она отстаёт...
Ответить | Правка | Наверх | Cообщить модератору

115. Сообщение от mamba (?), 06-Дек-21, 18:44	+3 +/–
Alibaba так не считает https://www.youtube.com/watch?v=4Yhn2Zq3mHA
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #171

116. Сообщение от А где же каменты (?), 06-Дек-21, 18:56	–1 +/–
Постгрес нравится, но девелопер похож на обиженку- видимо чего-то недодали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

117. Сообщение от Аноним (117), 06-Дек-21, 19:14	+11 +/–
> детища оракула Вот и выросло поколение... Хоть википедию бы почитали бы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

118. Сообщение от Имя (?), 06-Дек-21, 19:31	–1 +/–
Вот когда постгрес предложит мне мультимастер из коробки, встроенный колоночный движок и миллион приблуд вокруг потому что протокол мускуля знают все сто лет, тогда я подумаю слезть с марии. Всему свое, нет серебрянной пули (ну конечно если вы разработкой заняты а не чтением блогов).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #120

119. Сообщение от nik (??), 06-Дек-21, 19:57	+/–
че за бред ?? -- все изменения в данных и в том же UNDO сохраняются в REDO, и пофиг длинная там транзакция или короткая, при сбросе питания все откатится до последнего COMMIT, а то что "не успело" -- вернется в пред. состояние из UNDO.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #141

120. Сообщение от leap42 (ok), 06-Дек-21, 19:59	+/–
>> ...когда постгрес предложит мне мультимастер из коробки... Опять 25... Зачем нужен мультимастер? Почти любая СУБД тормозит при записи на диск. Если у вас есть другой мастер, то с ним надо реплицироваться. Данные второго мастера тож надо писать другими словами. Производительность НЕ увеличивается. Это работало только с MySQL который всё тянул на одном(!) ядре процессора и иногда упирался в него. Убогий костыль для масштабирования по процу. Postgres уже лет 15 умеет в многоядерность, ему этот бред ни к чему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #128

121. Сообщение от Catwoolfii (ok), 06-Дек-21, 20:05	+2 +/–
В текущей версии postgres половина названных проблем уже не актуальна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

122. Сообщение от Catwoolfii (ok), 06-Дек-21, 20:08	+2 +/–
У мускула определенно есть некоторые плюсы в сравнении со слоном, но только не язык запросов. Такой огрызок еще поискать надо...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #124

123. Сообщение от Alexander (ok), 06-Дек-21, 20:14	+1 +/–
>> уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/ > Ну это Мария. А это всё тот же ISAM, только навороченный. Но > я не пробовал, ничего сказать не могу. Вы что-то путаете: --- Конечно, помимо достоинств у кластера Galera есть и ограничения (перевод фрагмента с официального сайта MariaDB):     Репликация поддерживается только для таблиц в формате InnoDB; --- Да, я тоже не пробовал :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

124. Сообщение от Ilya Indigo (ok), 06-Дек-21, 20:17	–2 +/–
> У мускула определенно есть некоторые плюсы в сравнении со слоном, но только > не язык запросов. Такой огрызок еще поискать надо... Я хоть от одного мамкиного слонёнка конкретику услышу с примерами и пруфами, или только один глупый и необоснованный детский бред!?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

125. Сообщение от Аноним (125), 06-Дек-21, 20:35	+1 +/–
GOOGLE vs ORACLE Мужик-же просто отрабатывает подъемные у нового (старого) работодателя. Все, увы, банально и старо, как мир. :)
Ответить | Правка | Наверх | Cообщить модератору

126. Сообщение от michelle (??), 06-Дек-21, 20:40	+/–
В 2004 делал проект биллинга провайдера на постгресе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #215

127. Сообщение от Онаним (?), 06-Дек-21, 20:43	–2 +/–
Што, мужику отказали в возможности безальтернативный VACUUM в MySQL добавить? Так не приживётся он там, без него хорошо.
Ответить | Правка | Наверх | Cообщить модератору

128. Сообщение от Онаним (?), 06-Дек-21, 20:44	+/–
Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций. А для бОльших гарантий есть синхронный мультимастер, Galera Cluster называется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #138, #173

129. Сообщение от Онаним (?), 06-Дек-21, 20:46	–1 +/–
Можно, вопрос какой ценой. А в случае мускула всё это очень легко и ненавязчиво.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #163

130. Сообщение от Онаним (?), 06-Дек-21, 20:47	+/–
На самом деле уже давно нет. И даже для логов нет. Потому что при обрыве записи эти гигасы вылетят на LOCK+REPAIR, и будет прелесть. InnoDB очень шустр ныне. Годится и для write-mostly в т.ч. Объёмы итоговые только негуманные, но со сжатием терпимо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

131. Сообщение от Онаним (?), 06-Дек-21, 20:52	+/–
Тут два вопроса: 1) Зачем конкретно? В большинстве случаев вообще не требуется. Единственное исключение - компактинг избыточно разлапистого индекса. 2) OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

132. Сообщение от Онаним (?), 06-Дек-21, 20:53	+/–
Точнее второе даже не вопрос. Онлайновая операция это ныне на InnoDB, которая допускает DML во время выполнения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

133. Сообщение от Онаним (?), 06-Дек-21, 20:55	+/–
Бред. Ну или эксплуатация на системе, не умеющей в write barrier - там что угодно развалится, не только InnoDB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #139

134. Сообщение от Онаним (?), 06-Дек-21, 20:56	–2 +/–
Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт. Окей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #149

135. Сообщение от Онаним (?), 06-Дек-21, 20:57	+3 +/–
Ну, на рельсах можно и постгрю, хуже уже не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

136. Сообщение от Онаним (?), 06-Дек-21, 20:58	+/–
Если InnoDB не наполнять очень хитрым образом - необходимости в OPTIMIZE TABLE обычно не существует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #189

137. Сообщение от Онаним (?), 06-Дек-21, 21:00	–1 +/–
Понятно. Упёрся в кривую ORM, свалил всё на RDBMS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #153

138. Сообщение от ыы (?), 06-Дек-21, 21:01	+1 +/–
>Это про возможность продолжить писать в условиях полного отказа одного из мастеров В самом деле? Кто бы мог подумать ... На самом деле все транзакции писавшиеся на отказавшем мастере откатываются... и все что не дошло до другого мастера тоже откатывается. Вы же не зафиксируете половину атомарной записи, правда? :) Поэтому с точки зрения "продолжать писать при отказе" - мультимастер ничем не отличается от обычного переключения слэйва на праймори...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #145, #146

139. Сообщение от Мимо_проходил (?), 06-Дек-21, 21:07	+/–
> Бред. > Ну или эксплуатация на системе, не умеющей в write barrier - там > что угодно развалится, не только InnoDB. Словья-то какие воспроизводим. Ещё бы знали, что это значит )))) Write barrier тут вообще не причём. Причём тут то, что Inno не обеспечивает WAL для UNDO. Вот и всё. Сделано это из соображений, да, скорости. И, в общем, имеет право на жизнь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #140, #142, #143, #144

140. Сообщение от Онаним (?), 06-Дек-21, 21:08	+/–
Короче я не знаю, как ты умудрился InnoDB развалить - у меня за долгие годы не получилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #195

141. Сообщение от Мимо_проходил (?), 06-Дек-21, 21:09	+/–
> че за бред ?? -- все изменения в данных и в том > же UNDO сохраняются в REDO, и пофиг длинная там транзакция или > короткая, при сбросе питания все откатится до последнего COMMIT, а то > что "не успело" -- вернется в пред. состояние из UNDO. Нет, это не так. Возможны состояния, когда UNDO не оказалось в REDO, а изменённые блоки уже на диске.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

142. Сообщение от Онаним (?), 06-Дек-21, 21:10	+/–
И что значит при чём тут WB. Когда двиг выставляет fsync()/fdatasync()/sync_file_range(), он ожидает, что на диске к моменту завершения будет всё, что он отписал, и заказал. Если WB нет - с энной вероятностью хрен оно будет на диске вовремя, и рандомное выключение приведёт к интересному.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

143. Сообщение от Онаним (?), 06-Дек-21, 21:20	+/–
Ну и да, какой WAL для UNDO вы вообще собрались писать, если к моменту коммита в REDO данные только в REDO. Далее его флашим в таблицу как придётся, когда по нагрузке посвободнее например, даже если что-то отвалится, делаем рефлаш. Двойная нагрузка на флаш, ещё и с чтением из REDO, если из буфера вылетело, выйдет только когда REDO заполнен. Это две разные парадигмы - либо пишем в REDO и флашим в таблицу потом, либо сразу пишем в таблицу и далее начинаются пляски с UNDO: мы либо переносим, и тогда получаем двойную нагрузку в момент транзакции, либо как в постгресном, пишем CoW'ом, и тогда надо вакуумить. Если у нас UNDO есть, REDO уже не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

144. Сообщение от Онаним (?), 06-Дек-21, 21:26	+/–
Могу ещё подсказать как без WB редо развалить. Всё не просто, а очень просто: мы флашим редо, выставляем синк на таблицу, выставляем синк на поинтеры редо. Если таблица на диск не попала, а поинтеры внезапно попали - имеем лютый 3.14ц, в таблице старые данные, в редо уже ничего. С андо попроще, с андо корова конечно решает, но зато корову вакуумить надо регулярно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

145. Сообщение от Онаним (?), 06-Дек-21, 21:41	–1 +/–
Э-э-э, вы точно себе представляете, как репликация работает? Я вижу, что нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #176

146. Сообщение от Онаним (?), 06-Дек-21, 21:47	–1 +/–
Ну и я же не зря написал: с потерей части транзакций. Если потеря части данных не вызывает проблем. Для всякой негарантированной статистики - более чем. Если у нас нет строгих требований к упорядоченности - мы ещё и на любой мастер писать можем, да, будет лаг синхронизации, но см. в начало строчки. Если нам нужен мульти-мастер с синхронностью и откатом - берём галеру. Там да, не завершённая транзакция откатывается со всех узлов. Но при этом нам не нужно ничего "переключать" - как только транзакция упавшего мастера откатится, следующие будут выполнены. Более того, мы можем на любой мастер писать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #213

147. Сообщение от arisu (ok), 06-Дек-21, 21:53	+/–
> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё > актуальны. так причина «мы не хотим платить специалистам, поэтому наберём макак по объявлениям» всегда будет актуальна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

148. Сообщение от arisu (ok), 06-Дек-21, 21:58	+2 +/–
> А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами > и оптимизациями банально не потянет. потянет и это. просто надо применить Секретную Оптимизацию: выгнать на мороз тебя и тебе подобных «специалистов».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

149. Сообщение от arisu (ok), 06-Дек-21, 22:01	+3 +/–
> Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт. > Окей. вообще-то так и есть. но ты этого всё равно не поймёшь, что очевидно по глупости твоего комментария.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

150. Сообщение от arisu (ok), 06-Дек-21, 22:10	+1 +/–
> Где миллион волонтеров давно используют постгрес и довольны. а кто в постгрес нормально не смог… ну, я не уверен, что это хороший вариант для MySQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

151. Сообщение от arisu (ok), 06-Дек-21, 22:12	+1 +/–
> А всем ли нужен мощный оптимизатор запросов? да. потому что сделать из мощного хреновый просто, а вот наоборот — очень сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

152. Сообщение от penetrator (?), 06-Дек-21, 22:53	+/–
https://www.red-gate.com/simple-talk/databases/sql-server/t-.../ Heaps are tables without a clustered index. Я вообще не собирался лезть в детали, я про то что в MSSQL ЕСТЬ КУЧИ. Это онли про "Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча" Куча вполне себе возможна, доступна и используется в MSSQL. Это то, что я имел ввиду. Куча возможна если нет ниодного кластерного индекса, которым обычно и является первичный ключ (первый и часто единственный кандидат). Никакие нюансы терминологии меня в душе не ебали в тот момент. Я только вернул кучи назад в MSSQL Server! С этим же все согласны? Ну вот и отлично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #202

153. Сообщение от AleksK (ok), 06-Дек-21, 23:07	–2 +/–
> Понятно. Упёрся в кривую ORM, свалил всё на RDBMS. Понятное дело если бы ты её писал то она бы летала и была бы сделана идеально. Эх жаль мир потерял такого специалиста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #154

154. Сообщение от Онаним (?), 06-Дек-21, 23:15	–1 +/–
Не переживай, не потерял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

155. Сообщение от Онаним (?), 06-Дек-21, 23:18	+/–
Похоже как раз на частичный коммит REDO в отсутствии WB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

156. Сообщение от Онаним (?), 06-Дек-21, 23:18	+/–
Ну или fsync кто-то бездумно выключил xD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

157. Сообщение от Аноним (157), 06-Дек-21, 23:26	+1 +/–
Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с 8-й версии. А в многопоточке он всегда работал быстрее (гугл и другие крупные конторы делали свои патчи, чтобы у них MySQL не тормозил на параллельных запросах, эти патчи потом вошли и в Машку и в Перкону). Была даже статья с названием типа "Нет больше медленных слонов" (только я ее не нашел). Произошло это больше 12-ти лет назад. До этого Postgres с его транзакционностью был медленнее MySQL с его MyISAM без какой либо атомарности. IMHO чуть ли не единственная причина, почему MySQL не закапали еще лет 10 назад - WordPress работает только с ним и армия php'шников использовала преимущественно MySQL. А так как веб разработка есть почти в любом проекте и эта сфера довольно большая - то MySQL до сих пор широко распространен (в средней конторе админу проще поддерживать одну базу - MySQL, чем две MySQL для веба и Postgres для остального). Кроме того, Postgres нужно настраивать, чтобы он работал быстро, а в MySQL с этим попроще. Еще в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы вообще не выполнял, а MySQL позволял довольно широкие отклонения). Щас с России по статистике Posqtgres занимает нишу больше, чем MySQL. У буржуинов противоположная ситуация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #158, #161, #180, #228

158. Сообщение от YetAnotherOnanym (ok), 06-Дек-21, 23:36	+/–
> армия php'шников использовала преимущественно MySQL > в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов Чувствуется какая-то связь между этими наблюдениями...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

159. Сообщение от kai3341 (ok), 06-Дек-21, 23:42	+1 +/–
> Попутал ты всё. Какой "кластерный первичный ключ"? https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html Each InnoDB table has a special index called the clustered index that stores row data. Typically, the clustered index is synonymous with the primary key. Не попутал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #206

160. Сообщение от Фан (?), 07-Дек-21, 00:04	–2 +/–
MySQL будучи карманной игрушкой Oracle по определению не может быть конкурентноспособной РСУБД, по причини наличия у Oracle своей собственной РСУБД Слон же не принадлежит никому и поэтому искуственных палок в колеса ему не вставляют, есть еще Firebird, но это классическая РСУБД без новомодных приблуд, к слову очень хорошая
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #179, #183

161. Сообщение от _hide_ (ok), 07-Дек-21, 00:32	+1 +/–
> Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с > 8-й версии. Это Вы про скороть чтения на одинаковом железе или сравниваете корпоративный сервер от именитых поставщиков с шаред хостингами? > А в многопоточке он всегда работал быстрее (гугл и > другие крупные конторы делали свои патчи, чтобы у них MySQL не > тормозил на параллельных запросах, эти патчи потом вошли и в Машку > и в Перкону). Вы про что опять? У MySQL всегда была большая проблема с планировщиком, а многопточность -- это требование от больших дядь на чтение во время записи, которое не имеет ничего общего с реальной многопоточностью при выборке данных (её как таковой нет ни в Мускуле, ни в ПГ) > Была даже статья с названием типа "Нет больше > медленных слонов" (только я ее не нашел). Произошло это больше 12-ти > лет назад. До этого Postgres с его транзакционностью был медленнее MySQL > с его MyISAM без какой либо атомарности. Да, что-то вспоминаю, сравнивали MyISAM и PG? Сейчас это очень своевременно и да, не имеет никакого отношения к скорости, ПГ НИКОГДА НЕ СРАВНИТСЯ ПО СКОРОСТИ, просто это стоит намного дороже в плане проектирования (планировщик у него работает почти идеально, но Вы же не можете гарантировать наличие индексов всегда? Вот и упретесь в то, что если железка не может хранить все индексы в памяти и с ними играться, то ни о каком сравнении с MySQL-ом речи быть не может). И опять же, на ПГ только искать? Для этого есть совсем другие решения, а при записи он посасывает. > IMHO чуть ли не единственная причина, почему MySQL не закапали еще лет > 10 назад - WordPress работает только с ним и армия php'шников > использовала преимущественно MySQL. А так как веб разработка есть почти в > любом проекте и эта сфера довольно большая - то MySQL до > сих пор широко распространен (в средней конторе админу проще поддерживать одну > базу - MySQL, чем две MySQL для веба и Postgres для > остального). Кроме того, Postgres нужно настраивать, чтобы он работал быстро, а > в MySQL с этим попроще. Еще в MySQL раньше были менее > жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы > вообще не выполнял, а MySQL позволял довольно широкие отклонения). Очень субъективно, но, на мой взгляд, тут не синтаксис сыграл свое (а он местами просто уг), а то, что на 64МБ оперативки он вполне себя живенько чувствовал. > Щас с России по статистике Posqtgres занимает нишу больше, чем MySQL. У > буржуинов противоположная ситуация. Он занимает нишу Оракла, а сайтовая ниша для MySQL-а у нас просто намного меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

162. Сообщение от Аноним (162), 07-Дек-21, 00:33	+/–
Выглядит как чувак не смог (занимался оптимизацией, которая по итогу оказалась на уровне 2000-х), ему сказали "и за что тебе платить?", он обидился, свалил и решил нагадить под дверь ораклам.
Ответить | Правка | Наверх | Cообщить модератору

163. Сообщение от Аноним (67), 07-Дек-21, 00:45	+/–
Именно. Или пусть расскажет как будет восстанавливать X траназакций котоые удалили спустя 10-15 секунд PITR. Хотя что такое 200 потерянных транзакций и кому это может быть интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

164. Сообщение от Степан (?), 07-Дек-21, 02:03	+/–
Работал недавно на проекте, которому уже почти 10 лет и который является топ 1 решением в своем домене в Америке. На нём используется как раз монга. Не сказать что мы, разработчики, рады этому факту, но работает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #174

165. Сообщение от Аноньимъ (ok), 07-Дек-21, 02:49	+/–
>слон медленнее мускуля только в кривых руках В переводе с опеннетского это видимо означает, что нужна команда высококлассных специалистов чтобы его базово настроить. Мускл же меня никогда не подводил и работал сразу из коробки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

166. Сообщение от Аноньимъ (ok), 07-Дек-21, 03:00	–1 +/–
Мамин илитарий, угомонись. ПХП программисты ничем не хуже сишников и сипипишников. Специалисты и профаны есть везде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #167, #186

167. Сообщение от arisu (ok), 07-Дек-21, 03:06	+/–
> ПХП программисты ничем не хуже сишников и сипипишников. ну да, почти как люди: две руки, две ноги, две задницы… в одну они едят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

168. Сообщение от Анончик (?), 07-Дек-21, 03:57	+2 +/–
тут пока одни капитаны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

169. Сообщение от Прохожий (??), 07-Дек-21, 05:36	–1 +/–
И какая альтернатива, о великий эксперт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #223

170. Сообщение от Виктор (??), 07-Дек-21, 05:45	+/–
Используйте инструменты по назначению, да не везде будут фишки остальных баз. Но свои функции для сайтов вполне справляется, если ты не фирма гигант конечно же!
Ответить | Правка | Наверх | Cообщить модератору

171. Сообщение от ddd2 (?), 07-Дек-21, 06:36	+/–
у них свое ответвление MySQL с 2008-2009 года. Там от родного MySQL только названия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #172

172. Сообщение от Простоник (ok), 07-Дек-21, 07:44	+/–
Админ у них просто героический. Для hi load эта штука не имеет необходимых механизмов. Амбразуры, похоже, приходится закрывать собственным  телом(пристройкой сарайчиков и землянок).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #175

173. Сообщение от leap42 (ok), 07-Дек-21, 08:06	+2 +/–
>> Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций. Вы не слушайте того кто вам такое говорит, он вообще не шарит.  Когда primary отказывает, ближайший standby становится мастером сам. Всё. Почему это лучше мультимастера? - Очень легко избежать split brain. С асинхронным мультимастером избежать split brain вообще не всегда возможно - вопрос только "когда". Синхронный мультимастер ставит на колени производительность при географическом удалении нод в 100%, и почти всегда даже если они рядом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #177

174. Сообщение от _ (??), 07-Дек-21, 08:15	+4 +/–
Чат для котегафф!?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

175. Сообщение от funny.falcon (?), 07-Дек-21, 08:28	–2 +/–
Думаю, их «сарайчики и землянки» больше походят на Форд-Нокс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #219

176. Сообщение от funny.falcon (?), 07-Дек-21, 08:35	+1 +/–
Какая репликация? Синхронная? Асинхронная? Синхронная с кворумом? На протоколе консенсуса?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #178

177. Сообщение от funny.falcon (?), 07-Дек-21, 08:41	+/–
Согласен на 99.99% Мультимастер действительно более живуч. Но действительно тормознее. Практически ни кому живучесть мультимастера не нужна. Время переключения реплики - обычно меньше 1 минуты (чаше всего, 10-20 секунд). Пять переключений в год - это доступность 99.999%. Этого достаточно даже для маркетплейсов и банков (хоть они и заявляют шесть девяток, но рады и пяти девяткам).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #214

178. Сообщение от Онаним (?), 07-Дек-21, 09:24	–1 +/–
Та, которая обсуждается. Но это слишком сложно, понимаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #181

179. Сообщение от Аноньимъ (ok), 07-Дек-21, 09:38	–1 +/–
А натуральные вставляют? Должен ли велик быть обязательно чьим-то чтобы вставлять ему палки в колёса?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

180. Сообщение от моррут (?), 07-Дек-21, 09:44	+/–
>Еще в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы вообще не выполнял, а MySQL позволял довольно широкие отклонения). при этом вполне синтаксически корректные конструкции в запросе MySQL  вполне может сожрать без каких-либо замечаний, но ничего при этом не сделать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

181. Сообщение от funny.falcon (?), 07-Дек-21, 09:47	+/–
Видимо, для вас действительно сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

182. Сообщение от fuggy (ok), 07-Дек-21, 10:28	+1 +/–
> нет ни unsigned, не int1 и int3 unsigned нет в SQL стандарте. int1 это для тех кто не умеет boolean. int3 вообще какая-то эзотерика, никому не нужная. smallint достаточно. Ну уж в количестве типов тягаться с PostgreSQL не стоит. Там есть array, intrange, daterange, xml, json, inet, геометрические типы. Даже банального uuid нет. > ALTER TABLE ... ADD ... AFTER ... В стандарте у колонок нету порядка. Да функция удобная, но без неё можно прожить. Про CONSTRAINT CHECK ничего не хочешь сказать? Он как бы есть, но его нет. И уж сравнивать по фичам MySQL не стоит. Подключаемые движки, это единственное что пока есть. Они хороши только для определённой нагрузки. Зато нет набора типов индексов, с помощью которых можно улучшить некоторые операции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #191

183. Сообщение от Старший аноним (?), 07-Дек-21, 10:31	–1 +/–
У вас какой уровень IQ, вьюноша? Oracle взял свистоподелку и слепил из нее нормальный продукт. Но если изначально были родовые травмы, то от них очень трудно избавиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #193, #225

184. Сообщение от kai3341 (ok), 07-Дек-21, 10:38	+/–
> Документация с тобой не согласна: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html Ознакомьтесь с документацией. Между optimize table и autovacuum есть огромная разница. Начиная с того, что optimize table -- это опция, которую можно не запускать никогда, а вот autovacuum отключать очень не рекомендуется Ещё раз -- это разница между демоном, который в норме должен работать постоянно, и опцией, которую можно годами не запускать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #233

185. Сообщение от _hide_ (ok), 07-Дек-21, 10:39	–1 +/–
> Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb? Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью операций. Пишем в лог, читаем из данных и лога (причем все проблемы синхронизации и доступности решает движок БД, разве не классно?). Когда не Hello World, а 300 клиентов пишут/читают единовременно из одного набора данных, такие вопросы вызывают лишь улыбку. И да ISAM-кие движки всегда были ReadOnly after write? Или были какие-то решения для обхода ограничений?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #187

186. Сообщение от Наме (?), 07-Дек-21, 10:42	–1 +/–
> Мамин илитарий, угомонись. > ПХП программисты ничем не хуже сишников и сипипишников. > Специалисты и профаны есть везде. Я о том, что пэхэпёр вряд ли в свой профессиональной жизни плотно сталкивается с потрохами разных СУБД. Ему это просто не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

187. Сообщение от Наме (?), 07-Дек-21, 10:47	+/–
> Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью > операций. Пишем в лог, читаем из данных и лога (причем все > проблемы синхронизации и доступности решает движок БД, разве не классно?). Каких ещё блокировок? Вот есть у тебя ряд реализаций MVCC, одна хранит историю в виде исходных строк в том же месте, где они были до удаления/изменения, другая пишет, условно, диффы в другое место, а на прежнем месте городит сложную структуру из цепных ссылок, третья делает что-то среднее между первым и вторым -- какие-то удалённые строки держит на прежнем месте, какие-то выносит в отдельную помойку, а какие-то изменения просто хранит в виде инструкций в журнале изменений. Какой способ лучше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #194

188. Сообщение от _hide_ (ok), 07-Дек-21, 10:48	+/–
> другая проводит пересортировку таблиц. Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи имеет свою цену и одна из них -- большое количество мертвых данных) заполняется сортированным для чтения набором данных и пересчитанными индексами (после релокейта деток, приходится и индексы пересчитывать) > освобождает счётчик транзакций (изменений) В том контексте, которые используется мной, такие действия выполняются при коммите транзакции (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #197

189. Сообщение от Аноним (192), 07-Дек-21, 10:49	+/–
Точнее сказать - если не удалять из нее данные)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #190

190. Сообщение от Онаним (?), 07-Дек-21, 10:51	–1 +/–
Перепутали с постгрёй и вакуумом. InnoDB - это не постгря, она умеет заполнять освобождённые страницы при добавлении данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #207

191. Сообщение от Онаним (?), 07-Дек-21, 10:53	+/–
Зато есть отсутствие vacuum, которое автоматически улучшает куда больше, чем тот самый набор индексов. Кстати индексы по (даже не хранимым) вычисляемым полям в MariaDB давно можно делать, и поэтому ряд вещей таким способом и решается. Но соглашусь, маразм с отсутствием DESC индексов решён пока только в ванильной восьмёрке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #216

192. Сообщение от Аноним (192), 07-Дек-21, 10:56	+/–
А вот это в корне не так, если говорить о б-жественном InnoDB. InnoDB не поддерживает OPTIMIZE напрямую, вместо этого все данные из таблицы копируются во временную таблицу, которая потом замещает оригинальную.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

193. Сообщение от ыы (?), 07-Дек-21, 10:57	+1 +/–
>Oracle взял свистоподелку и слепил из нее нормальный продукт. Oracle купил (не взял, а именно купил) за много много долларооов, систему которая в тот момент уже  надежно работала на половине сайтов в инете. После продажи, автор, сделал крутой финт ушами- он потребовал чтобы Oracle вернула mysql сообществу.. и когда оракл покрутил пальцем у виска - автор сделал форк... с тех пор так все и идет- оракл делает СО СВОИМ  mysql то что считает нужным, а сообщество периодически недовольно ропщет недовольное СВОИМ mysql...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #196, #198

194. Сообщение от _hide_ (ok), 07-Дек-21, 11:06	+/–
> Каких ещё блокировок? Мы скоро обсуждать будем ассемблерные вставки? Кто это пишет дифы? Никто никаких дифов в набор данных не пишет (да и в логи пишутся отнють не дифы, а новые значение полей): либо переписывает измененный набор данных/релоцирует его и пишет заново, помечая старые данные как свободное место (MySQL), либо пишет весь блок отдельно и отмечает это в метазаписях как ожидающий вакуума (PG). VACUUM блокирует часть данных при релокации. MySQL-у Optimize Table нужен как таковой, только при использовании запросов вне индекса (при сканировании), PG требует этого "для обслуживания". > какие-то изменения просто хранит в виде инструкций в журнале изменений Хранить инструкции в журнале? Что за бред, такое было когда-то в InnoDB, но уже давно всплыло, а если журнал будет повреждён? Конец атомарности, разрушены внешние ссылки и вообще ахтунг и ручное восстановление. > Какой способ лучше? Для пользователей и разработчик-прикладников, лучше именно гибридный способ с повторным использованием освободившегося места (и фрагментацией как проблемой), потому что это даёт серьезный прирост к скорости (путем нагрузки на CPU и контроллер, но не на IO), нежели полное копирование всех данных при обновлении. Если брать разработчиков этих СУБД, то второй способ хорош тем, что его можно очень качественно отладить и оптимизировать, тем самым заняв нишу систем с низкой степенью отказа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #199

195. Сообщение от 1 (??), 07-Дек-21, 11:21	+/–
У тебя просто не было длинных транзакций ... А так разваливается и при резком выключении питания (гасится ИБП) так и при нехватке свободного места ... гасится мониторингом. А так ... Ну что спорить-то какой нож лучше ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #220

196. Сообщение от ыы (?), 07-Дек-21, 11:28	+/–
1 миллиард долларов США если интересно :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193

197. Сообщение от Наме (?), 07-Дек-21, 11:30	+/–
>> другая проводит пересортировку таблиц. > Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем > не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи > имеет свою цену и одна из них -- большое количество мертвых > данных) заполняется сортированным для чтения набором данных и пересчитанными индексами > (после релокейта деток, приходится и индексы пересчитывать) >> освобождает счётчик транзакций (изменений) > В том контексте, которые используется мной, такие действия выполняются при коммите транзакции > (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник) Ты не в курсе. У Слона счётчик циркулярный, ещё и "меридианный". Уроборос этакий. Без вакуума он заканчивается и всё фризится. Ну и чем тогда пурген отличается от вакуума(кроме чистки счётчика)? Риторический вопрос. В действительности, ни одна из реализаций не лучше другой. Это очередная Кока-кола против Пепси-колы. И не коммите, а фиксации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

198. Сообщение от ыы (?), 07-Дек-21, 11:30	+/–
к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #205

199. Сообщение от Наме (?), 07-Дек-21, 11:33	+/–
Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных). Но не всегда. Если у тебя строка огромная, а поменял ты в ней один символ, то могилить (как делает Слон и Инно тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и этим экономится и пространство хранение и оперативное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #201

200. Сообщение от 1 (??), 07-Дек-21, 11:41	+/–
Не вижу комментариев - зачем они нужны, когда есть SQLite ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #203, #218

201. Сообщение от _hide_ (ok), 07-Дек-21, 11:42	+/–
> Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных). > Но не всегда. Если у тебя строка огромная, а поменял ты > в ней один символ, то могилить (как делает Слон и Инно > тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и > этим экономится и пространство хранение и оперативное. Это микрооптимизация поверх определенных типов данных, которая даёт существенный прирост на синтетике. С практической т.з., если запись изменилась, то перезапись выгоднее, как минимум, своей простотой, да и частая посимвольная замена в строке говорит о проблемах совсем другого рода при проектировании приложения. ЗЫ Но да, прикольно, не знал про это
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

202. Сообщение от Наме (?), 07-Дек-21, 11:43	+/–
Не серчай. Вокруг этой темы перебор всякой терминологии. У многих в результате каша. Я просто попытался немного ситуацию прояснить. Так что, PK (первичный ключ) это Ограничение и оно НИКОГДА не реализуется кучей. Реализуется "кластерным" (исходная куча тю-тю, если была) или доп. (некластерным) индексом (доп. в смысле дополнительным к исходной куче, которая в этом случае никуда не девается, просто по данным этой кучи строится В-древо, которое эти данные структурирует, что и упрощает с одной стороны поиск, с другой -- создаёт основу для реализации условия уникальности).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

203. Сообщение от ыы (?), 07-Дек-21, 11:47	+/–
Это настолько самособой разумеется, что даже холиварить повода нет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

204. Сообщение от Аноним (204), 07-Дек-21, 11:57	+/–
>> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё >> актуальны. >Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования >Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает. Я мог конечно не так понять, но вроде обоснования были такие. Там вроде одна из проблем была - массированные обновления строк. У постгреса с этим не очень хорошо (по крайней мере было, как сейчас - не знаю), тормозил нещадно по сравнению с мускулем. Поясню. У других БД (оракл, мускуль...) строка обновляется на том же месте, где валяется (in-place), т.е. ее физическое положение в блоках не меняется, кроме редких случаев. А постгря вместо редактирования старой строки тупо добавляет измененнную новую. Вроде должно быть даже быстрее, типа некий аналог Copy-on-write. Проблемы возникают, когда на таблицу навешаны индексы. Индекс - упорядоченная последовательность значений, где с каждой строчкой индекса хранится ссылка на исходную строку в таблице, в каких блоках она находится по каким смещениям. В оракле-мускуле, если в строке обновляются поля, не входящие в индекс, индекс не редактируется (адрес строки в таблице не поменялся). А вот в постгре даже при обновлении не-индексных полей надо каждый раз искать в индексе и обновлять на адрес новой, обновленной строки - там уже другой адрес, уже в других блоках ошивается строка, т.е в индексе хранится фигня, надо исправить. Т.е. представь, в таблице у тебя один-два-три индекса, для поисков, а ты 24/7 массированно меняешь поля, не входящие в индекс - и совершается куча лишней (в сравнении с мускулем) работы по обновлению индексов, да еще и куча мусора остается в виде старых исключенных строк, которые какой-нибудь автовакуум подобрать должен, периодически внося свои тормоза и задержки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #249

205. Сообщение от arisu (ok), 07-Дек-21, 12:08	+/–
> к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку... не надо. там от продукта жизнедеятельности монти осталось примерно столько же, сколько в их компиляторе php от оригинального php.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198

206. Сообщение от Наме (?), 07-Дек-21, 12:15	+/–
>> Попутал ты всё. Какой "кластерный первичный ключ"? > https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html > Each InnoDB table has a special index called the clustered index that > stores row data. Typically, the clustered index is synonymous with the > primary key. > Не попутал. Кластерный индекс это... хм... индекс. А Первичный ключ это... ограничение. Просто в силу того, что в МС Сиквеле (и в Инно) зачастую разраб при определении отношения сразу пишет требование ограничения PK (причём, по умолчанию оно реализуется именно кластерным индексом), то ему и невдомёк, что Ограничение и Индекс это не одно и тоже. Совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #210

207. Сообщение от Аноним (207), 07-Дек-21, 12:29	+/–
Вообще-то умеет. но чтобы это узнать надо прочитать документацию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

208. Сообщение от InuYasha (??), 07-Дек-21, 12:40	+/–
вот как рыз вы в кучу мешаете носки с помидорами. PHP был задуман для добавления динамики в хоумпаги, а большой спрос и низкая квалификация родили монстра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #229, #240

209. Сообщение от InuYasha (??), 07-Дек-21, 12:45	+/–
> Oracle не выделяет должных ресурсов Смешно. Не то чтобы они купили май для захоронения, но вообще Oracle скатывает всё в помойную яму, какапывая тоннами лицензий, контрактов, подписок и поливая вендорлоками.
Ответить | Правка | Наверх | Cообщить модератору

210. Сообщение от kai3341 (ok), 07-Дек-21, 13:12	+/–
> Each InnoDB table has a special index called the clustered index Я настоятельно рекомендую использовать терминологию официальной документации, а не вашу собственную
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #211, #212, #235

211. Сообщение от Наме (?), 07-Дек-21, 13:35	+/–
Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично. Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

212. Сообщение от Наме (?), 07-Дек-21, 13:35	+/–
Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично. Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

213. Сообщение от Наме (?), 07-Дек-21, 13:37	+/–
Если нужен "мультимастер", то берём Oracle RAC, а БД размещаем поверх ceph.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

214. Сообщение от Наме (?), 07-Дек-21, 13:39	–2 +/–
Наоборот мульти-мастер это про производительность. Просто единственный реализованный нормальный мультимастер это RAC, где энное кол-во экземпляров работают с одним набором файлов данных (которые сами могут быть пространственно размазаны поверх сетевой фс). А галера эта муть какая-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

215. Сообщение от cadmi (?), 07-Дек-21, 13:46	+1 +/–
Когда Вадиму Михееву (работал в соседнем здании и был с ним знаком) в 1995 году понадобилось написать телефонный биллинг для МГТС в Красноярске, он написал половину тогдашнего постгреса :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

216. Сообщение от fuggy (ok), 07-Дек-21, 14:26	+1 +/–
Вакуум это лишь отложенное амортизированное время операции на вставку/удаление, за счёт чего это операции эти операции выполняются быстро без необходимости копировать строки в REDO. То есть устаревшие версии строк хранятся в самой таблице и раздувают её, что конечно плохо. Вся лишь разница где хранятся старые версии строк и если вакуум выполняется регулярно, то будет лишь небольшой процент мёртвого места. Но вакуум выполняется в фоне и не занимает основной поток операций. Функциональные индексы и PostgreSQL есть, недавно появились и покрывающие индексы, а кроме того там ещё есть полезные частичные индексы, что в разы уменьшает размер индекса. Частичные индексы позволяют проиндексировать только нужные значения для выборки, не включая оставшиеся ненужные строки. А что касается типов индексов, то кроме банального B-tree, есть и более интересные вроде BRIN, Bloom. Гео индексы тоже есть, но они не всем нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

218. Сообщение от Аноним (219), 07-Дек-21, 15:06	+/–
зачем нужны комментарии?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

219. Сообщение от Аноним (219), 07-Дек-21, 15:08	+2 +/–
это чо за тачка?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

220. Сообщение от Онаним (?), 07-Дек-21, 15:28	+/–
Ну короче да, смысла спорить нет - я хз как вы умудряетесь InnoDB развалить, видимо руки должны быть правильно заточены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

221. Сообщение от cadmi (?), 07-Дек-21, 15:32	+/–
А как там у mysql с ddl в транзакциях? Научились уже? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

222. Сообщение от анон ессно (?), 07-Дек-21, 15:54	+/–
С Postgre95.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #232

223. Сообщение от flexagoon (ok), 08-Дек-21, 11:36	–1 +/–
Да любые NoSQL БД
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #251

224. Сообщение от anonymous (??), 08-Дек-21, 12:23	+/–
> MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит. Небольших сайтов вроде FB.com и pinterest
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

225. Сообщение от Фан (?), 08-Дек-21, 20:55	+/–
В чем смысл коммерческой корпорации Oracle вкладывать в MySQL в ущерб своей Oracle? Или Oracle Corporation уж стал Oracle Foundation? И не разрабатывает MySQL по остаточном признаку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #230, #252

226. Сообщение от Аноним (226), 08-Дек-21, 20:59	–3 +/–
Что первое что второе - детские погремушки на фоне того же mssql.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #231, #243

228. Сообщение от Анонимус314 (?), 08-Дек-21, 21:58	+/–
Вот откуда берется это про "нужно настраивать"? Там все основные настройки в конфиге откомментированы и интуитивно понятны, насколько помню (2 года настройкой СУБД не занимался).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

229. Сообщение от ыы (?), 08-Дек-21, 22:15	+/–
>а большой спрос и низкая квалификация кто же такой умный задумывал его для хоумпегов которые будут верстаться при низком спросе и высокой квалификации? какие такие хоумпеги имелись в виду?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

230. Сообщение от ыы (?), 08-Дек-21, 22:18	+/–
Мускул ниразу не конкурент ораклу. Совершенно разные целевые сегменты... мускулем они закрывают нишу... и делают совершенно правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225

231. Сообщение от ыы (?), 08-Дек-21, 22:19	+/–
mssql на линухе уже научилась через шаред мемори работать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226

232. Сообщение от Аноним (232), 09-Дек-21, 05:30	+/–
Postgres95
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222

233. Сообщение от Аноним (232), 09-Дек-21, 05:40	+/–
Зависит от типа нагрузки, с одной без optimize table у вас диск переполнится, а с другой можно и автоваккум отключить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #236

234. Сообщение от Аноним (234), 09-Дек-21, 06:46	+1 +/–
А я его еще больше ку. (c)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

235. Сообщение от Онаним (?), 10-Дек-21, 09:19	+/–
У пользователей MSSQL проблемы с тем, что они умудряются мешать индексы с констрейнтами, при этом их механически разделяя :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

236. Сообщение от Онаним (?), 10-Дек-21, 09:21	+/–
Каким образом "переполнится диск" без optimize table, если innodb прекрасно умеет писать данные в освободившиеся страницы, не потрудитесь объяснить? Нет, есть там пара очень специфичных случаев, но вы их вряд ли приведёте, с ними мало кто сталкивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233

237. Сообщение от Онаним (?), 10-Дек-21, 09:26	+/–
У вас MVCC уже без лога работает? И даже с индексами? На самом деле нет. Постгря всё так же прекрасно пишет redo log, просто его назвали wal.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #238

238. Сообщение от Онаним (?), 10-Дек-21, 09:27	+/–
Тьфу плин MVCC. ACID, конечно же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

239. Сообщение от Онаним (?), 10-Дек-21, 09:32	+/–
Какой ISAM, о чём вы. InnoDB к ISAM вообще отношения не имеет, это продукт Innobase, причём эту компаху Oracle купила задолго до санок с MySQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

240. Сообщение от Онаним (?), 10-Дек-21, 09:33	–1 +/–
Интернет задумывался как сеть для оборонного ведомства, а 640кб в своё время хватало всем. Windows 1.0 тоже был очередным унылым файловым менеджером для DOS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #241, #242

241. Сообщение от Онаним (?), 10-Дек-21, 09:34	+/–
(вещи, которые оказались удобны и востребованы - имеют свойство перерастать себя)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240

242. Сообщение от Онаним (?), 10-Дек-21, 09:37	+/–
Freax тоже когда-то был личной поделкой под себя любимого, просто чтобы миних на 386 не пользовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240

243. Сообщение от Онаним (?), 10-Дек-21, 09:40	+/–
В MSSQL особо убивает стохастика оптимизатора - финальный план запроса может меняться 100500 раз при просто последовательном выполнении одного и того же запроса. Мало того без профайлера не разгребёшь, где засада, так ещё и каждый запуск выливается в разные планы, и результаты профайлера не бьются друг с другом. Наши виндодевелоперы с ним трахаются с завидной регулярностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #244

244. Сообщение от arisu (ok), 10-Дек-21, 11:02	+/–
как удивительно: сервер видит повторяющиеся паттерны — и оптимизирует под них. вот же гад какой, а!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #243 Ответы: #245

245. Сообщение от Онаним (?), 10-Дек-21, 12:09	+/–
Ды не, если бы он стабильно делал, а там именно стохастика где-то, потому что планы таки повторяются, но в ряде случаев для этого надо, чтобы фаза луны сошлась. По незадаче, это как раз те случаи, где запрос здоровый, и есть какая-то проблема... которую потрекать даже с профайлером трудно, поскольку стохастика не даёт предсказать результат изменений в самом запросе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #246

246. Сообщение от arisu (ok), 10-Дек-21, 12:18	+/–
ну. пробует разные планы, ведёт статистику. в принципе, нормальный метод оптимизации — для реальных нагрузок, где несколько плохих планов нивелируются последующими выигрышами. вполне логично, что при таких раскладах бенчмарки имеют такой же смысл, как и любая другая ИБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #247

247. Сообщение от Онаним (?), 10-Дек-21, 12:31	+/–
Ды там дело не в бенчмарке. Там проблема проблему трекнуть. Оно на половине его стохастики допустим где-то костыляется, и вместо 0.01 сек выдаёт 2-3 сек на том же запросе, при _отсутствии_ параллельных запросов - в идеальном сферическом тесте в вакууме. При этом план совершенно другой, чем вызвано - никто не объясняет, как фиксить - непонятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #248

248. Сообщение от Онаним (?), 10-Дек-21, 12:33	+/–
(точнее понятно, и уже зафиксили) Разбили запрос на три и объединение через хранимку, в итоге вместо 0.01-2.6 стали почти стабильные 0.07-0.14, плохо, но лучше, чем вот та задница.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247

249. Сообщение от www2 (??), 22-Дек-21, 07:25	+/–
В MySQL можно одновременно читать одну и ту же запись, а читать и обновлять - нет. Набегающие толпы читающих клиентов могут надолго заблокировать запись для обновления. А в PostgreSQL каждый читающий клиент будет читать эту запись внутри своей транзакции, а в рамках другой транзакции эта запись будет обновлена, так что следующие читающие клиенты начнут новые транзакции и прочитают уже обновлённую запись. https://ru.wikipedia.org/wiki/PostgreSQL#%D0%9C�...) В общем, для сайтиков, где данные обновляются не так часто, а чаще читаются, MySQL, наверное, подойдёт лучше. Если же данные чаще обновляются, чем читаются, то PostgreSQL подойдёт лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204 Ответы: #253

250. Сообщение от www2 (??), 22-Дек-21, 07:30	+/–
>Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума) А вакуум над ibdata1 не помешал бы. Полное резервное копирование с последующим восстановлением из резервной копии - так себе альтернатива для вакуума. Но тем, у кого полная резервная копия делается за полчаса, а перерыв в работе в несколько часов не особо критичен, MySQL пойдёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

251. Сообщение от www2 (??), 22-Дек-21, 07:42	+/–
На SQL по крайней мере стандарт есть и даже те, кто его не придерживается, изображают что-то более-менее одно и то же. Оптимизатор SQL-запросов способен учитывать статистику данных в таблицах, наличие индексов по нужным полям и налету может изменить порядок соединения таблиц. При изменении данных в базе SQL проверяются ограничения, ссылочная целостность. В SQL есть полноценные транзакции с возможностью откатиться до промежуточной контрольной точки. А вот на NoSQL никаких стандартов нет, каждый выдумывает что-то своё. И похоже всё это на закат солнца вручную.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223 Ответы: #254

252. Сообщение от www2 (??), 23-Дек-21, 13:12	+/–
Версий много и все они могут быть правдивы как по отдельности, так и вместе: - диверсифицируют риски, - расширяют количество потенциальных клиентов, - предоставляют полный сервис по решению проблем клиента в комплексе, а не ограничиваются задачей впарить один конкретный продукт всем подряд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225

253. Сообщение от Всем Анонимам Аноним (?), 28-Янв-22, 15:03	+/–
Вы, наверное, про MyISAM? В MySQL разные движки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249

254. Сообщение от Всем Анонимам Аноним (?), 28-Янв-22, 15:06	+/–
Все зависит от цели. Когда много данных и нужна скорость, но целостность - не проблема, то почему бы нет. Хотя я согласен, Гугл даже строит новую базу себе типа SQL, называется Spanner. Вначале думали да, все проблемы можно возложить на код, но потом пришли к выводу, что проще чтобы база данных этим все-таки занималась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

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

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