The OpenNET Project / Index page

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



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

"Представлена новая значительная ветка СУБД MariaDB 11"  +/
Сообщение от opennews (??), 28-Дек-22, 15:03 
Спустя 10 лет с момента основания ветки 10.x представлен выпуск СУБД MariaDB 11.0.0, в котором предложено несколько значительных улучшений и изменений, нарушающих совместимость. Ветка пока имеет качество альфа-выпуска и станет готовой для рабочих применений после проведения стабилизации. Формирование следующей значительной ветки MariaDB 12, содержащей изменения, нарушающие совместимость, ожидается не ранее чем через 10 лет (в 2032 году)...

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

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

Оглавление

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

1. Сообщение от Аноним (1), 28-Дек-22, 15:03   –22 +/
Никогда не понимал этого насильного насаживания немощных васянофорков в дистрибутивах. Сабж очередное подтверждение, что ничего хорошего из этого не получится. Ситуация может немного отличаться, когда и основной проект васяноподелка, но это явно не тот случай.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #7

2. Сообщение от Аноним (7), 28-Дек-22, 15:07   +5 +/
> Формирование следующей значительной ветки MariaDB 12, содержащей изменения, нарушающие совместимость, ожидается не ранее чем через 10 лет (в 2032 году).

Вот это жесть. За 10 лет там накопится такой груз легаси что развитие фактически остановится, и СУБД, и так значительно отстающая по возможностям от того же постгреса, вообще станет бесполезной игрушкой.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #6, #42, #108

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

4. Сообщение от Аноним (3), 28-Дек-22, 15:10   +/
зато у mariadb есть galera и можно сделать отказоустойчивый, "синхронный" кластер
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #5, #11, #36

5. Сообщение от Аноним (3), 28-Дек-22, 15:11   +/
а у postgresql всё сложно с кластеризацией. В бесплатном варианте по крайней мере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #24

6. Сообщение от Аноним (1), 28-Дек-22, 15:12   +1 +/
Я так это понял, сабж изначально позиционируется как легаси решение для легаси пхп кода, других применений и не планировалось. А вот Оракел, как это не удивительно, занимается развитием -- ему очень интересно занять и такие ниши своими решениями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

7. Сообщение от Аноним (7), 28-Дек-22, 15:14   +9 +/
> васянофорков

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

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

8. Сообщение от Аноним (8), 28-Дек-22, 15:16   +1 +/
> значительная ветка

для лл: это major version series по-русски

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

9. Сообщение от Аноним (7), 28-Дек-22, 15:17   +/
В MySQL развития никакого нет. Оракелу интересно подсаживать пользователей на свой коммерческий продукт, а ниши занимать ему смысла вообще никакого нет. Да и силёнок не хватит - опенсорсных конкурентов слишком много и они слишком сильные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #13, #72

10. Сообщение от Аноним (1), 28-Дек-22, 15:17   –10 +/
А вот это просто смешно слышать. До чего люди готовы доверять любому скаму в интернете, удивительно.

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

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

11. Сообщение от Аноним (7), 28-Дек-22, 15:18   –1 +/
У постгреса есть patroni где то же самое делается элементарно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #16

12. Сообщение от birdie (ok), 28-Дек-22, 15:31   –5 +/
Я жду версии MariaDB/MySQL/Percona/whatever, которую не надо вручную настраивать под каждый host. Это выглядит как дебилизм. MongoDB/Redis молча встают и работают без настроек вообще. Postgres тоже, кажется, сто лет с ним дело не имел.

Все итерации MySQL на тяжёлом production (>50 запросов в секунду; пару slave'ов для зеркалирования и backups) надо настраивать вручную ради вменяемой производительности.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #33, #43, #64, #104

13. Сообщение от Аноним (1), 28-Дек-22, 15:34   +/
Зато в MariaDB имитация бурной деятельности и ухудшение пользовательских характеристик. Только всё полезное почему-то вечно тянут из апстрима, а не наоборот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #25

14. Сообщение от birdie (ok), 28-Дек-22, 15:36   +/
Major на русский в контексте версии очень затруднительно перевести. Как и minor.

Я бы просто оставил музыкальные термины: мажорный и минорный.

Или, как вариант, "основной" (да, ведь major = это основа для будущих выпусков), "неосновной" - снова беда, в русском как-то всё грустно: https://sinonim.org/a/%D0%BE%D1%81%...

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

15. Сообщение от Аноним (20), 28-Дек-22, 15:44   –2 +/
> весовую модель (cost model),

Cost Model - уже давно переводится в России как модель, основанная на стоимости запроса, а оптимизатор по такой модели - оптимизатор по стоимости ("https://www.rdtex.ru/glossary/c/C47209/")

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

16. Сообщение от гага (?), 28-Дек-22, 15:56   +1 +/
патрони это нагромождение скриптов которые крутят логической мастер-слейв репликацией, далековато до синхронного кластера
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #101

17. Сообщение от Аноним (17), 28-Дек-22, 16:01   +8 +/
Ну вот и пользуйтесь оракловской версией.
Только вот факт, что MySQL названа в честь старшей дочери, а MariaDB в честь младшей, вы отрицать не сможете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #20, #48

18. Сообщение от Аноним (20), 28-Дек-22, 16:09   +1 +/
Ыще одын форумный иксперд. Чтобы "подсаживать" пипл на Oracle DB, у фирмы Oracle есть ограниченная по ресурсам и фичам редакция Oracle DB XE (Express Edition), на которую можно установить APEX - бесплатную Low Code платформу создания WEB-приложений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

20. Сообщение от Аноним (20), 28-Дек-22, 16:12   –3 +/
Типа, да я полный дурак, но отрицать что 1 + 1 даже вы не сможете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #89, #100

21. Сообщение от Аноним (21), 28-Дек-22, 16:12   +4 +/
козырный. вышла козырная ветка MariaDB. внатуре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

22. Сообщение от Аноним (22), 28-Дек-22, 16:36   +1 +/
Вот ты смешной, оракл тебе промыла мозги маркетингом.

оракл в мускуле так ничего и не развила. Тоже самое как апач "разививает" опенофис, один в один. Стагнация во все поля. Зато обратная совместимость, тут ничего не скажешь.

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

24. Сообщение от Аноним (22), 28-Дек-22, 16:37   +/
А Mysql — томат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

25. Сообщение от Аноним (22), 28-Дек-22, 16:38   –3 +/
Новость прочитай наконец уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #73

26. Сообщение от Аноним (22), 28-Дек-22, 16:40   +1 +/
Потом эти автонастраивальщики светят голым задом в интернет всеми данными. Монго ДБ раньше таким баловались, как раз тем о чём ты говоришь. Потом перестали сделали нормально как везде.

На новость про таких же глупцов как ты https://opennet.ru/opennews/art.shtml?num=53438

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

27. Сообщение от Аноним (22), 28-Дек-22, 16:41   –1 +/
Кнопка "исправить" ждёт, мой дорогой Аноним.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

29. Сообщение от ip1982 (ok), 28-Дек-22, 16:56   –1 +/
> В отдельный пакет вынесены символические ссылки для совместимости с MySQL.

Никогда не понимал, почему разработчики софтин беспокоятся о чём-либо кроме наполнении DESTDIR при make install.

Они всё равно делают это криво.

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

31. Сообщение от ip1982 (ok), 28-Дек-22, 16:57   –1 +/
> модель, основанная на стоимости запроса

Нет, спасибо.

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

33. Сообщение от Аноним (33), 28-Дек-22, 17:03   +1 +/
Перкона,если не ошибаюсь,по умолчанию на локалхост вешается. В чем проблема с хостами?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #110

35. Сообщение от penetrator (?), 28-Дек-22, 17:40   +/
вот только NDB этот васяно форк от автора не хочет сапортить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

36. Сообщение от penetrator (?), 28-Дек-22, 17:41   +/
галера - это убожество, NDB наше всё
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #66

38. Сообщение от VitalyE (?), 28-Дек-22, 17:51   +/
И теперь битрикс с конскими join заработает быстрее?? (нет)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #69, #80

42. Сообщение от YetAnotherOnanym (ok), 28-Дек-22, 18:05   +/
> развитие фактически остановится

Ога. Аноним не может работать с БД, в которой развесистость фич не прирастает каждый день.

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

43. Сообщение от YetAnotherOnanym (ok), 28-Дек-22, 18:07   +/
> на тяжёлом production (>50 запросов в секунду

Это на каком железе 50 запросов в секунду - "тяжёлый production"?

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

46. Сообщение от Аноним (1), 28-Дек-22, 18:29   +1 +/
Хм, у меня на локалхосте около 10000 апдейтов и 50000 селектов в минуту и с этим справляется sqlite. Выборка из нескольких связанных таблиц. Не сказал бы, что прямо хайлоад, но видимо можно заявлять, что это хайлоад? Загрузка процессора несколько процентов, вот io немного забито и sqlite периодически блокируется. Хуже было, когда между запуском воркеров не было слипов, они сразу блокируют sqlite когда долбятся писать в неё одновременно. Но сейчас это случается только когда у ядра проблемы с памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #50, #103

47. Сообщение от Аноним (20), 28-Дек-22, 18:41   +2 +/
Изначальный перевод "Cost Based Optimization" (CBO) - оптимизация, основанная на стоимости запроса (стоимости ресурсов сервера баз данных, задействованных при запросе, рассчитываемых на основе собранных статистик по объектам ДБ) в России пошел от Oracle DB, где этот метод впервые заменил старый метод оптимизации "Rule Based Optimization" (RBO) - оптимизация, основанная на правилах.

Так, что "ваше мнение очень важно для нас. Оставайтесь на линии. Пи-пип-пи".

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

48. Сообщение от Омномним (?), 28-Дек-22, 19:19   +4 +/
Ну допустим я съехал назад на оракловую версию в нескольких крупных аппликухах потому, что в MariaDB с 10.6 начиная конкретно убили page flushing - он теперь в один поток идёт, и когда у тебя полтера и компрессия - становится задорно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #62, #70, #77

49. Сообщение от Омномним (?), 28-Дек-22, 19:25   +4 +/
Оракл в мускуле сделала достаточно нововведений, которые ждали долго и бесполезно.
Online DDL, descending indexes, JSON, подключаемую аутентификацию, нормальный TLS, многопоточное перестроение индексов при DDL, нормальную реализацию GTID, человеческие атомарные DDL, человеческие хинты к запросам, и т.д. и т.п. В MariaDB всё это тоже либо бэкпортили либо делали позже, и криво-косо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

50. Сообщение от Омномним (?), 28-Дек-22, 19:25   +/
SELECT session WHERE user = по первичному ключу из помещающейся в память таблички? :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #57

51. Сообщение от Омномним (?), 28-Дек-22, 19:26   +/
Вот поэтому лучше читать в оригинале.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

52. Сообщение от Омномним (?), 28-Дек-22, 19:27   +/
Битрикс
Заработает
Быстрее

У вас аж три взаимоисключающих термина в одном вопросе.

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

53. Сообщение от pashev.ru (?), 28-Дек-22, 19:45   –1 +/
Переводы это не твой конёк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

57. Сообщение от Аноним (1), 28-Дек-22, 20:19   +1 +/
Вся база помещается, но она не в памяти, требуются постоянные запись/чтение на диск иначе данные будут потеряны безвозвратно. Никаких индексов, ничего. Выборка вида select * from table where table.foreignkey == ? и потом последняя по времени запись из таблицы, привязанной к этой, если определённые данные поменялись, то добавляется новая запись в той таблице. Либо обновляются существующие в этой. Либо записывается событие в отдельную таблицу при определённых условиях. 1 строка айди, 1 строка foreignkey, 5 интов, 5 дат. Вот таких выборок очень много и эти данные постоянно обновляются, последние 2000 записей, у каждого воркера выборка по своему foreign key, обязательно производится селект из 2 связанной таблицы, где данные (они не обновляются и не удаляются), вот там последний по дате. Всего 5 таблиц, по 2 из них используются только по числу воркеров раз при запуске. Есть несколько триггеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

59. Сообщение от Анони (?), 28-Дек-22, 20:25   –2 +/
Ты SQL-разраб, DBA или пересказываешь статью 10-летней давности?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

61. Сообщение от BrainFucker (ok), 28-Дек-22, 20:40   +/
> Объявлены устаревшими innodb_flush_method и innodb_file_per_table.

В смысле file per table там теперь по дефолту или больше нельзя так?

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

62. Сообщение от Аноним (62), 28-Дек-22, 21:20   +/
Кто заставлял обновляться на версию, которая вас не удовлетворяет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #63, #65

63. Сообщение от Омномним (?), 28-Дек-22, 21:24   +1 +/
> Кто заставлял обновляться на версию, которая вас не удовлетворяет?

Никто. Поэтому обновились на версию, которая удовлетворяет. Вот только это оракловая версия :)

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

64. Сообщение от Омномним (?), 28-Дек-22, 21:25   +/
Возьми DBF. Сердито и сердито.
А так ты пытаешься тапки с водолазным костюмом сравнить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

65. Сообщение от Омномним (?), 28-Дек-22, 21:32   +1 +/
Ну и там выбор так-то стоит из овна и овна... в 10.5 дедлоки (из-за которых кмк buffer pool instances и всё причитающееся и выкинули), в 10.6 однопоточный флаш. В ванильке (оракловой) компрессия до кучи удачно выкинута в write threads, т.е. можно регулировать нагрузку без игр с флашем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

66. Сообщение от Омномним (?), 28-Дек-22, 21:34   +/
Нормально все с галерой, нефига. Даже особо уметь готовить не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

67. Сообщение от Омномним (?), 28-Дек-22, 21:36   +/
Скорее всего по дефолту, общий головной tablespace давно пора выкинуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

68. Сообщение от vvm13 (?), 28-Дек-22, 21:59   –1 +/
"Oracle DB, где этот метод впервые заменил старый метод оптимизации "Rule Based Optimization" (RBO) "
Это звучит примерно как в "Windows 95 впервые появились 32-хбитные программы и длинные имена файлов".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #102

69. Сообщение от vvm13 (?), 28-Дек-22, 22:04   +/
Оптимизация SQL-запросов - такая сложная штука, что даже от самых лучших оптимизаторов не ждите чудес.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

70. Сообщение от Уася (?), 28-Дек-22, 22:21   –4 +/
проблема не в базе, а в не желании разобраться.
У меня всё работает. Просто надо быть профессионалом своего дела а не пользователем готового.
В моём случае база не работала корректно если запускать её на линуксе без модулей ядра поддержки железа.
южныймост сам цпу северный мост и даже видеокарта, представьте_себе, не будут работать корректно без корректно установленных модулей ядра(драйверов).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #75

72. Сообщение от Прохожий (??), 28-Дек-22, 22:51   +1 +/
>Оракелу интересно подсаживать пользователей на свой коммерческий продукт

И причём здесь MySQL, которая не совместима с их коммерческой СУБД?

>опенсорсных конкурентов слишком много и они слишком сильные

PostgreSQL, MariaDB - вот и все "сильные конкуренты", если говорить о реляционных СУБД. И, конечно, коммерческая СУБД от Oracle уделывает их обоих практически во всём, кроме, пожалуй, цены. Но здесь хорошо считать общую стоимость владения, и может оказаться, что "не всё так однозначно".

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

73. Сообщение от Аноним (73), 29-Дек-22, 00:07   +1 +/
Читаешь новость, а там:
* В MariaDB смогли бекпортировать код из MySQL 5.7 спустя пять лет после релиза оного.
* Отметить это решили перестановкой стуль^W^W переименованием mysqldump в mariadbdump и mysqladmin в mariadbdbdadmin.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

74. Сообщение от ИмяХ (?), 29-Дек-22, 00:25   +/
Вооо, классная версия, ваще круто. Я нормальный.
Ответить | Правка | Наверх | Cообщить модератору

75. Сообщение от Аноним (75), 29-Дек-22, 00:31   +/
> база не работала корректно если запускать её на линуксе без модулей ядра поддержки железа.

Можно подробнее? Что за железо, что за модули (из стандартной поставки ядра не запустились? или потребовалось скачивать с сайта производителя)? Какой дистрибутив?

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

76. Сообщение от tty0 (?), 29-Дек-22, 02:08   +3 +/
Они не глупцы. Им платят деньги за результат. После них хоть трава не расти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

77. Сообщение от Аноним (77), 29-Дек-22, 04:01   +/
Если у тебя не WordPress, который и является источником популярности MySQL, потому что не умеет что-то другое, то мне не понятно, почему ты не используешь Postgres...

Legacy, работа на заказчиков, которые жестко указывают СУБД - вряд ли твой случай. Вломы разобраться с начальной настройкой Postgres и поэтому ты просто используешь MySQL, в котором с эти сильно проще. Ну так с косяками fsync ты же разбирался - выходит тоже не похоже не причину.

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

78. Сообщение от Аноним (78), 29-Дек-22, 06:01   +/
Любители постргеса, живете в России и пользуйтесь. Все равно ничего другого нет. А весь мир, включая и Китай, использует MySQL и Mariadb. Отличная новость. Давно ждали ветку 11.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #97

79. Сообщение от Fyjybv111 (?), 29-Дек-22, 07:20   +1 +/
А вы знаете, что раст позволяет безопасно работать с памятью! По этому его нужно переписать на раст)))
Ответить | Правка | Наверх | Cообщить модератору

80. Сообщение от Anonysimus (?), 29-Дек-22, 08:23   +1 +/
Битрикс и так зарабатывает быстро
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

84. Сообщение от Омномним (?), 29-Дек-22, 10:00   –1 +/
> не понятно, почему ты не используешь Postgres...

Потому что я не люблю DBF в красивой обёртке. Вы всё ещё вакуумите? Тогда мы идём к вам.
Сетап - правильно замечено - через задницу. Это из мелочей.
Репликации нормальной нет. Мастер-мастер и синхронный кластер - только через навесные костыли. Ну ладно, второе в MySQL тоже через галеру на соплях. Но первое-то?
Просто не мазохист, извиняйте.

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

85. Сообщение от Омномним (?), 29-Дек-22, 10:01   +/
И да, где в этой поделке компрессия? Компрессия отдельных полей мне не нужна, поля мелкие, агрегировать - будет геморрой с выборкой. Нужна компрессия строк или страниц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

86. Сообщение от Омномним (?), 29-Дек-22, 10:11   +/
Есть один момент с коммерческой оракловой СУБД, даже 2, нет, даже 3, по которым она в другой весовой категории, и это не плюс.
- Тяжеловесность (на мелких нодах, где MySQL работает влёгкую с минимальным потреблением памяти, это вообще не стартует)
- Тяжеловесность конфигурации (сетап оной - лютейший геморрой, MySQL же легко деплоится почти куда угодно, и позволяет не сильно изголяться, в совершенно разных классах задач)
- Отсутствие возможности быть self-maintained. Селф-саппорта не предполагается изначально, а в тяжёлых случаях можно поиметь очень крутые периоды простоя из-за тщательнейших саппортовых процедур.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #94

87. Сообщение от Омномним (?), 29-Дек-22, 10:13   –1 +/
Ещё MSSQL забыли. Та ничего, если не принимать в расчёт совершенно ***ший оптимизатор запросов, стохастика которого периодически способна ставить раком даже самые простейшие запросы. Но та тоже селф-саппорта не предполагает вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

89. Сообщение от Аноним (89), 29-Дек-22, 10:53   +/
самокритично
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

90. Сообщение от Аноним (90), 29-Дек-22, 10:54   –1 +/
> Потому что я не люблю DBF в красивой обёртке. Вы всё ещё вакуумите? Тогда мы идём к вам.

Чё там в мыскле и ее деривативах, удаление строк за время жизни Вселенной реализовано, или еще десять лет ждать надо? Кстати, в связке с так надрачиваемым master-master удаление 10-15 млн. строк получается еще эффектнее.

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

91. Сообщение от Омномним (?), 29-Дек-22, 11:24   +/
Оно таки реализовано.
А не как в DBF - отметил и оставил, когда-нибудь там завакуумится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #93

92. Сообщение от 1 (??), 29-Дек-22, 11:33   –3 +/
Windows Server 2022. MariaDB не работает без NVIDIA драйвера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

93. Сообщение от Аноним (90), 29-Дек-22, 11:56   +/
Дык известно как оно в мыскле реализовано - несчастные 10 млн записей будут на одиночном сервере может за пару часов таки удалятся, если перед этим дропнуть индексы. А вот в разлюбезном master-master разве что ваши пра-правнуки дождутся завершение операции. И да, в это время все другие запросы будут сасай-кудасай. Но зато никакого вакуума, что верно, то верно, такой мастерский DDoS от разрабов превзойти сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #96

94. Сообщение от Аноним (90), 29-Дек-22, 12:00   –1 +/
> MySQL работает влёгкую с минимальным потреблением памяти

Минимальное потребление это обязательно не менее 50% наличной памяти вынь и положь, и чтобы это было не менее 1G в абсолютном исчислении. В противном случае запустится, но работать практически не будет, ибо будет постоянно сканировать таблицы поклав на индексы.

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

95. Сообщение от Омномним (?), 29-Дек-22, 13:10   +/
Гонево. У меня очень много таких мелких инстансов под клиентский сервис.

KiB Mem :  1481992 total,   360812 free,   441440 used,   679740 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
1205 mysql     20   0 1718988 191420   5232 S   0.0 12.9 760:09.10 /usr/sbin/mariadbd

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

96. Сообщение от Омномним (?), 29-Дек-22, 13:13   +/
И снова гонево, у меня cleanup более, чем 10 миллионов записей, ежесуточно отрабатывает очень шустро, и не ставит раком идущие процессы. В плане масштаба, слова RADIUS accounting, Zabbix history, mobile billing о чём-нибудь говорят?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

97. Сообщение от Омномним (?), 29-Дек-22, 13:15   +/
В вашей географии как-то вообще всегда была сильна страсть к маргинальщине...
Бзды, постгресы...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

98. Сообщение от Аноним (98), 29-Дек-22, 13:46   +/
> Объявлены устаревшими innodb_file_per_table

Прелестно, место теперь никак не высвободить после массового delete/truncate без ворочанья всего монструозного ibdata*.

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

99. Сообщение от Омномним (?), 29-Дек-22, 14:35   +1 +/
Вы о чём. У этого поезда заднего хода нет, просто innodb_file_per_table теперь будет всегда включено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

100. Сообщение от Аноним (7), 29-Дек-22, 14:42   +1 +/
Отрицать что 1 + 1 что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #106

101. Сообщение от Аноним (7), 29-Дек-22, 14:43   –1 +/
Синхронный тоже есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

102. Сообщение от vvm13 (?), 29-Дек-22, 20:55   +1 +/
Когда я познакомился с DB2 (в 90-х годах), там ни RBO, ни хинтов в принципе не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

103. Сообщение от Аноним (103), 29-Дек-22, 23:24   +/
Возьмите монгу или тарантул и не мучайтесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #105

104. Сообщение от Аноним (103), 29-Дек-22, 23:29   +/
>версии MariaDB/MySQL/Percona/whatever, которую не надо вручную настраивать под каждый host

Вы хотите странного.
> работают без настроек вообще

Не работают.
> Postgres тоже

Особенно постгрес.

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

105. Сообщение от Аноним (1), 29-Дек-22, 23:52   +/
Ну тут вопрос, можно ли оттранслировать в них схему для postgres/sqlite. Потому что в схеме эээ половина логики аппликухи. Что-то мне подсказывает, что привычные вещи с ними будут мучением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

106. Сообщение от Аноним (106), 30-Дек-22, 02:50   +/
что это французская комедийная драма, и еще телеканал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

107. Сообщение от DEF (?), 30-Дек-22, 08:29   +1 +/
Автор мускуля нормально устроился. Сначала продал свою базу данных Ораклу за 1 ярд, а потом такой белый и пушистый создал форк MariaDB, в противовес злобным корпорастам, которые "изуродовали" MySQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

108. Сообщение от DEF (?), 30-Дек-22, 08:50   +/
Ничего не будет копиться. Каждые 10 лет будут выпускать мажорную версию с тотальным заливом новых возможностей и сломом обратной совместимости. PHP делает также, но раз в 5 лет, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

110. Сообщение от пох. (?), 31-Дек-22, 21:29   +/
Проблема что такое умолчание нахрен никому не упало, кроме васянов с локалхостом.

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

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


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

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




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

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