The OpenNET Project / Index page

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

Представлена новая значительная ветка СУБД MariaDB 11

28.12.2022 11:38

Спустя 10 лет с момента основания ветки 10.x представлен выпуск СУБД MariaDB 11.0.0, в котором предложено несколько значительных улучшений и изменений, нарушающих совместимость. Ветка пока имеет качество альфа-выпуска и станет готовой для рабочих применений после проведения стабилизации. Формирование следующей значительной ветки MariaDB 12, содержащей изменения, нарушающие совместимость, ожидается не ранее чем через 10 лет (в 2032 году).

Проектом MariaDB развивается ответвление от MySQL, по возможности сохраняющее обратную совместимость и отличающееся интеграцией дополнительных движков хранения и расширенных возможностей. Развитие MariaDB курирует независимая организация MariaDB Foundation в соответствии с открытым и прозрачным процессом разработки, не зависящим от отдельных производителей. СУБД MariaDB поставляется вместо MySQL во многих дистрибутивах Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) и внедрена в таких крупных проектах, как Wikipedia, Google Cloud SQL и Nimbuzz.

Ключевым улучшением в ветке MariaDB 11 является перевод оптимизатора запросов на новую весовую модель (cost model), обеспечивающую более точное предсказание весов каждого плана выполнения запроса. Несмотря на то, что новая модель позволяет избавиться от некоторых узких мест с производительностью, не исключено, что она будет оптимальной не во всех сценариях и возможно замедление каких-то запросов, поэтому пользователям рекомендуется принять участие в тестировании и уведомить разработчиков в случае возникновения проблем.

Ранее используемая модель хорошо подходила для нахождения оптимального индекса, но имела проблемы с применимостью операций сканирования таблицы, сканирования индекса или выборки по диапазонам. В новой модели данный недостаток устранён за счёт изменения базового веса операций с движком хранения. При оценке производительности операций, зависящих от скорости работы с диском, таких как последовательное сканирование записей, теперь предполагается, что данные хранятся на SSD-накопителе, обеспечивающем скорость чтения на уровне 400 MB в секунду. Дополнительно проведён тюнинг и других весовых параметров оптимизатора, что, например, позволило реализовать возможность использования индексов для операций "ORDER BY/GROUP BY" в подзапросах и ускорить работу с очень маленькими таблицами.

Отмечается, что новая весовая модель позволит выбирать более оптимальный план выполнения запроса в следующих ситуациях:

  • При использовании запросов, охватывающих более 2 таблиц.
  • При наличии индексов, содержащих большое число одинаковых значений.
  • При использовании диапазонов, охватывающих более 10% таблицы.
  • При наличии сложных запросов, в которых не все используемые столбцы индексируются.
  • Когда используются запросы, привлекающие разные движки хранения (например, когда в одном запросе есть обращение к таблицам в движках InnoDB и Memory).
  • При использовании FORCE INDEX для улучшения плана запроса.
  • При ухудшении плана запроса в случае использования "ANALYZE TABLE".
  • Когда запрос охватывает большое число производных таблиц (большое число вложенных SELECT).
  • При использовании выражений ORDER BY или GROUP BY, подпадающих под индексы.

Основные нарушения совместимости в ветке MariaDB 11:

  • Права SUPER больше не позволяют выполнять действия, для которых доступны отдельно выставляемые привилегии. Например, для изменения формата бинарных логов потребуются права BINLOG ADMIN.
  • Удалена реализация буфера изменений в InnoDB.
  • Объявлены устаревшими innodb_flush_method и innodb_file_per_table.
  • Объявлена устаревшей поддержка имён mysql*.
  • Объявлено устаревшим выставление параметра explicit_defaults_for_timestamp в значение 0.
  • В отдельный пакет вынесены символические ссылки для совместимости с MySQL.
  • Значение параметра innodb_undo_tablespaces по умолчанию изменено на 3.


  1. Главная ссылка к новости (https://mariadb.org/mariadb-11...)
  2. OpenNews: Стабильный выпуск СУБД MariaDB 10.10
  3. OpenNews: MariaDB существенно меняет график выпусков
  4. OpenNews: Компания MariaDB представила прокси-сервер MaxScale 2.0
  5. OpenNews: Стабильный выпуск СУБД MariaDB 10
  6. OpenNews: Увидела свет СУБД MariaDB 10.0.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/58399-mariadb
Ключевые слова: mariadb
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (87) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 15:03, 28/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –22 +/
    Никогда не понимал этого насильного насаживания немощных васянофорков в дистрибутивах. Сабж очередное подтверждение, что ничего хорошего из этого не получится. Ситуация может немного отличаться, когда и основной проект васяноподелка, но это явно не тот случай.
     
     
  • 2.3, Аноним (3), 15:08, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –11 +/
    в этом вся суть так называемого "опенсорса"
     
  • 2.7, Аноним (7), 15:14, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > васянофорков

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

     
     
  • 3.10, Аноним (1), 15:17, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –10 +/
    А вот это просто смешно слышать. До чего люди готовы доверять любому скаму в интернете, удивительно.

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

     
     
  • 4.17, Аноним (17), 16:01, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ну вот и пользуйтесь оракловской версией.
    Только вот факт, что MySQL названа в честь старшей дочери, а MariaDB в честь младшей, вы отрицать не сможете.
     
     
  • 5.20, Аноним (20), 16:12, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Типа, да я полный дурак, но отрицать что 1 + 1 даже вы не сможете.
     
     
  • 6.89, Аноним (89), 10:53, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    самокритично
     
  • 6.100, Аноним (7), 14:42, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Отрицать что 1 + 1 что?
     
     
  • 7.106, Аноним (106), 02:50, 30/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    что это французская комедийная драма, и еще телеканал.
     
  • 5.48, Омномним (?), 19:19, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну допустим я съехал назад на оракловую версию в нескольких крупных аппликухах потому, что в MariaDB с 10.6 начиная конкретно убили page flushing - он теперь в один поток идёт, и когда у тебя полтера и компрессия - становится задорно.
     
     
  • 6.62, Аноним (62), 21:20, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Кто заставлял обновляться на версию, которая вас не удовлетворяет?
     
     
  • 7.63, Омномним (?), 21:24, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кто заставлял обновляться на версию, которая вас не удовлетворяет?

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

     
  • 7.65, Омномним (?), 21:32, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну и там выбор так-то стоит из овна и овна... в 10.5 дедлоки (из-за которых кмк buffer pool instances и всё причитающееся и выкинули), в 10.6 однопоточный флаш. В ванильке (оракловой) компрессия до кучи удачно выкинута в write threads, т.е. можно регулировать нагрузку без игр с флашем.
     
  • 6.70, Уася (?), 22:21, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    проблема не в базе, а в не желании разобраться.
    У меня всё работает. Просто надо быть профессионалом своего дела а не пользователем готового.
    В моём случае база не работала корректно если запускать её на линуксе без модулей ядра поддержки железа.
    южныймост сам цпу северный мост и даже видеокарта, представьте_себе, не будут работать корректно без корректно установленных модулей ядра(драйверов).
     
     
  • 7.75, Аноним (75), 00:31, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > база не работала корректно если запускать её на линуксе без модулей ядра поддержки железа.

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

     
     
  • 8.92, 1 (??), 11:33, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Windows Server 2022 MariaDB не работает без NVIDIA драйвера ... текст свёрнут, показать
     
  • 6.77, Аноним (77), 04:01, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя не WordPress, который и является источником популярности MySQL, потому что не умеет что-то другое, то мне не понятно, почему ты не используешь Postgres...

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

     
     
  • 7.84, Омномним (?), 10:00, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > не понятно, почему ты не используешь Postgres...

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

     
     
  • 8.85, Омномним (?), 10:01, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И да, где в этой поделке компрессия Компрессия отдельных полей мне не нужна, по... текст свёрнут, показать
     
  • 8.90, Аноним (90), 10:54, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чё там в мыскле и ее деривативах, удаление строк за время жизни Вселенной реализ... текст свёрнут, показать
     
     
  • 9.91, Омномним (?), 11:24, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Оно таки реализовано А не как в DBF - отметил и оставил, когда-нибудь там зава... текст свёрнут, показать
     
     
  • 10.93, Аноним (90), 11:56, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дык известно как оно в мыскле реализовано - несчастные 10 млн записей будут на о... текст свёрнут, показать
     
     
  • 11.96, Омномним (?), 13:13, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И снова гонево, у меня cleanup более, чем 10 миллионов записей, ежесуточно отраб... текст свёрнут, показать
     
  • 4.22, Аноним (22), 16:36, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот ты смешной, оракл тебе промыла мозги маркетингом.

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

     
     
  • 5.49, Омномним (?), 19:25, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Оракл в мускуле сделала достаточно нововведений, которые ждали долго и бесполезно.
    Online DDL, descending indexes, JSON, подключаемую аутентификацию, нормальный TLS, многопоточное перестроение индексов при DDL, нормальную реализацию GTID, человеческие атомарные DDL, человеческие хинты к запросам, и т.д. и т.п. В MariaDB всё это тоже либо бэкпортили либо делали позже, и криво-косо.
     
  • 5.59, Анони (?), 20:25, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ты SQL-разраб, DBA или пересказываешь статью 10-летней давности?
     
  • 3.18, Аноним (20), 16:09, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ыще одын форумный иксперд. Чтобы "подсаживать" пипл на Oracle DB, у фирмы Oracle есть ограниченная по ресурсам и фичам редакция Oracle DB XE (Express Edition), на которую можно установить APEX - бесплатную Low Code платформу создания WEB-приложений.
     
  • 3.35, penetrator (?), 17:40, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    вот только NDB этот васяно форк от автора не хочет сапортить
     
  • 3.107, DEF (?), 08:29, 30/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Автор мускуля нормально устроился. Сначала продал свою базу данных Ораклу за 1 ярд, а потом такой белый и пушистый создал форк MariaDB, в противовес злобным корпорастам, которые "изуродовали" MySQL.
     

  • 1.2, Аноним (7), 15:07, 28/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > Формирование следующей значительной ветки MariaDB 12, содержащей изменения, нарушающие совместимость, ожидается не ранее чем через 10 лет (в 2032 году).

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

     
     
  • 2.4, Аноним (3), 15:10, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    зато у mariadb есть galera и можно сделать отказоустойчивый, "синхронный" кластер
     
     
  • 3.5, Аноним (3), 15:11, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    а у postgresql всё сложно с кластеризацией. В бесплатном варианте по крайней мере.
     
     
  • 4.24, Аноним (22), 16:37, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А Mysql — томат.
     
  • 3.11, Аноним (7), 15:18, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У постгреса есть patroni где то же самое делается элементарно.
     
     
  • 4.16, гага (?), 15:56, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    патрони это нагромождение скриптов которые крутят логической мастер-слейв репликацией, далековато до синхронного кластера
     
     
  • 5.101, Аноним (7), 14:43, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Синхронный тоже есть.
     
  • 3.36, penetrator (?), 17:41, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    галера - это убожество, NDB наше всё
     
     
  • 4.66, Омномним (?), 21:34, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нормально все с галерой, нефига. Даже особо уметь готовить не надо.
     
  • 2.6, Аноним (1), 15:12, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я так это понял, сабж изначально позиционируется как легаси решение для легаси пхп кода, других применений и не планировалось. А вот Оракел, как это не удивительно, занимается развитием -- ему очень интересно занять и такие ниши своими решениями.
     
     
  • 3.9, Аноним (7), 15:17, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В MySQL развития никакого нет. Оракелу интересно подсаживать пользователей на свой коммерческий продукт, а ниши занимать ему смысла вообще никакого нет. Да и силёнок не хватит - опенсорсных конкурентов слишком много и они слишком сильные.
     
     
  • 4.13, Аноним (1), 15:34, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Зато в MariaDB имитация бурной деятельности и ухудшение пользовательских характеристик. Только всё полезное почему-то вечно тянут из апстрима, а не наоборот.
     
     
  • 5.25, Аноним (22), 16:38, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Новость прочитай наконец уже.
     
     
  • 6.73, Аноним (73), 00:07, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Читаешь новость, а там:
    * В MariaDB смогли бекпортировать код из MySQL 5.7 спустя пять лет после релиза оного.
    * Отметить это решили перестановкой стуль^W^W переименованием mysqldump в mariadbdump и mysqladmin в mariadbdbdadmin.
     
  • 4.72, Прохожий (??), 22:51, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Оракелу интересно подсаживать пользователей на свой коммерческий продукт

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

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

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

     
     
  • 5.86, Омномним (?), 10:11, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Есть один момент с коммерческой оракловой СУБД, даже 2, нет, даже 3, по которым она в другой весовой категории, и это не плюс.
    - Тяжеловесность (на мелких нодах, где MySQL работает влёгкую с минимальным потреблением памяти, это вообще не стартует)
    - Тяжеловесность конфигурации (сетап оной - лютейший геморрой, MySQL же легко деплоится почти куда угодно, и позволяет не сильно изголяться, в совершенно разных классах задач)
    - Отсутствие возможности быть self-maintained. Селф-саппорта не предполагается изначально, а в тяжёлых случаях можно поиметь очень крутые периоды простоя из-за тщательнейших саппортовых процедур.
     
     
  • 6.94, Аноним (90), 12:00, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > MySQL работает влёгкую с минимальным потреблением памяти

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

     
     
  • 7.95, Омномним (?), 13:10, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Гонево. У меня очень много таких мелких инстансов под клиентский сервис.

    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

     
  • 5.87, Омномним (?), 10:13, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ещё MSSQL забыли. Та ничего, если не принимать в расчёт совершенно ***ший оптимизатор запросов, стохастика которого периодически способна ставить раком даже самые простейшие запросы. Но та тоже селф-саппорта не предполагает вообще.
     
  • 2.42, YetAnotherOnanym (ok), 18:05, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > развитие фактически остановится

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

     
  • 2.108, DEF (?), 08:50, 30/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего не будет копиться. Каждые 10 лет будут выпускать мажорную версию с тотальным заливом новых возможностей и сломом обратной совместимости. PHP делает также, но раз в 5 лет, например.
     

  • 1.8, Аноним (8), 15:16, 28/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > значительная ветка

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

     
     
  • 2.14, birdie (ok), 15:36, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Major на русский в контексте версии очень затруднительно перевести. Как и minor.

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

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

     
     
  • 3.21, Аноним (21), 16:12, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    козырный. вышла козырная ветка MariaDB. внатуре.
     

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

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

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

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

     
     
  • 3.76, tty0 (?), 02:08, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Они не глупцы. Им платят деньги за результат. После них хоть трава не расти.
     
  • 2.33, Аноним (33), 17:03, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Перкона,если не ошибаюсь,по умолчанию на локалхост вешается. В чем проблема с хостами?
     
     
  • 3.110, пох. (?), 21:29, 31/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема что такое умолчание нахрен никому не упало, кроме васянов с локалхостом.

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

     
  • 2.43, YetAnotherOnanym (ok), 18:07, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > на тяжёлом production (>50 запросов в секунду

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

     
     
  • 3.46, Аноним (1), 18:29, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хм, у меня на локалхосте около 10000 апдейтов и 50000 селектов в минуту и с этим справляется sqlite. Выборка из нескольких связанных таблиц. Не сказал бы, что прямо хайлоад, но видимо можно заявлять, что это хайлоад? Загрузка процессора несколько процентов, вот io немного забито и sqlite периодически блокируется. Хуже было, когда между запуском воркеров не было слипов, они сразу блокируют sqlite когда долбятся писать в неё одновременно. Но сейчас это случается только когда у ядра проблемы с памятью.
     
     
  • 4.50, Омномним (?), 19:25, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    SELECT session WHERE user = по первичному ключу из помещающейся в память таблички? :D
     
     
  • 5.57, Аноним (1), 20:19, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вся база помещается, но она не в памяти, требуются постоянные запись чтение на д... большой текст свёрнут, показать
     
  • 4.103, Аноним (103), 23:24, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Возьмите монгу или тарантул и не мучайтесь.
     
     
  • 5.105, Аноним (1), 23:52, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тут вопрос, можно ли оттранслировать в них схему для postgres/sqlite. Потому что в схеме эээ половина логики аппликухи. Что-то мне подсказывает, что привычные вещи с ними будут мучением.
     
  • 2.64, Омномним (?), 21:25, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Возьми DBF. Сердито и сердито.
    А так ты пытаешься тапки с водолазным костюмом сравнить.
     
  • 2.104, Аноним (103), 23:29, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >версии MariaDB/MySQL/Percona/whatever, которую не надо вручную настраивать под каждый host

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

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

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

     

  • 1.15, Аноним (20), 15:44, 28/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > весовую модель (cost model),

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

     
     
  • 2.27, Аноним (22), 16:41, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кнопка "исправить" ждёт, мой дорогой Аноним.
     
  • 2.31, ip1982 (ok), 16:57, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > модель, основанная на стоимости запроса

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

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

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

     
     
  • 4.53, pashev.ru (?), 19:45, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Переводы это не твой конёк.
     
  • 4.68, vvm13 (?), 21:59, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "Oracle DB, где этот метод впервые заменил старый метод оптимизации "Rule Based Optimization" (RBO) "
    Это звучит примерно как в "Windows 95 впервые появились 32-хбитные программы и длинные имена файлов".
     
     
  • 5.102, vvm13 (?), 20:55, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда я познакомился с DB2 (в 90-х годах), там ни RBO, ни хинтов в принципе не было.
     
  • 2.51, Омномним (?), 19:26, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вот поэтому лучше читать в оригинале.
     

  • 1.29, ip1982 (ok), 16:56, 28/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > В отдельный пакет вынесены символические ссылки для совместимости с MySQL.

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

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

     
  • 1.38, VitalyE (?), 17:51, 28/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И теперь битрикс с конскими join заработает быстрее?? (нет)
     
     
  • 2.52, Омномним (?), 19:27, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Битрикс
    Заработает
    Быстрее

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

     
  • 2.69, vvm13 (?), 22:04, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Оптимизация SQL-запросов - такая сложная штука, что даже от самых лучших оптимизаторов не ждите чудес.
     
  • 2.80, Anonysimus (?), 08:23, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Битрикс и так зарабатывает быстро
     

  • 1.61, BrainFucker (ok), 20:40, 28/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Объявлены устаревшими innodb_flush_method и innodb_file_per_table.

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

     
     
  • 2.67, Омномним (?), 21:36, 28/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее всего по дефолту, общий головной tablespace давно пора выкинуть.
     

  • 1.74, ИмяХ (?), 00:25, 29/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вооо, классная версия, ваще круто. Я нормальный.
     
  • 1.78, Аноним (78), 06:01, 29/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Любители постргеса, живете в России и пользуйтесь. Все равно ничего другого нет. А весь мир, включая и Китай, использует MySQL и Mariadb. Отличная новость. Давно ждали ветку 11.
     
     
  • 2.97, Омномним (?), 13:15, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В вашей географии как-то вообще всегда была сильна страсть к маргинальщине...
    Бзды, постгресы...
     

  • 1.79, Fyjybv111 (?), 07:20, 29/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А вы знаете, что раст позволяет безопасно работать с памятью! По этому его нужно переписать на раст)))
     
  • 1.98, Аноним (98), 13:46, 29/12/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Объявлены устаревшими innodb_file_per_table

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

     
     
  • 2.99, Омномним (?), 14:35, 29/12/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы о чём. У этого поезда заднего хода нет, просто innodb_file_per_table теперь будет всегда включено.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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