The OpenNET Project / Index page

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

22.10.2015 22:51  Сравнение производительности MariaDB 10.1 и MySQL 5.7

Разработчики MariaDB провели тестирование производительности веток СУБД MySQL 5.7, MySQL 5.6, MariaDB 10.0 и MariaDB 10.1. Тестирование проводилось на сервере с 4-ядерным CPU Intel и 64Гб ОЗУ с использованием приложения sysbench на таблице, содержащей 1 млн записей. Наилучшие показатели продемонстрировал MySQL 5.6.27, а наихудшие - MySQL 5.7.9, разрыв между которыми оказался на уровне 10-12%. На втором месте оказался MariaDB 10.1, а на третьем MariaDB 10.0. Производительность MariaDB 10.1 увеличилась по сравнению с MariaDB 10.0 на 2-5%. Разница между производительностью MySQL 5.7 и MariaDB 10.1 составила 4-11%.



  1. Главная ссылка к новости (https://blog.mariadb.org/maria...)
  2. OpenNews: Стабильный выпуск СУБД MariaDB 10.1
  3. OpenNews: Компания Oracle анонсировала стабильный релиз MySQL 5.7
Лицензия: CC-BY
Тип: Тема для размышления
Ключевые слова: mariadb, mysql, benchmark
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Линейный вид | Ajax | Показать все | RSS
 
  • 1.1, pavlinux, 00:30, 23/10/2015 [ответить] [смотреть все]
  • +1 +/
    Постгрес где?!
     
     
  • 2.2, Аноним, 00:47, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]
  • –10 +/
    Я вижу только Регресс.
     
  • 2.4, asavah, 00:58, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]
  • –20 +/
    а где firebird, oracle, mssql, sqlite, sybase, db2 ща phoronix-у накатаю тел... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.15, eRIC, 07:01, 23/10/2015 [^] [ответить] [смотреть все]  
  • –16 +/
    это авторы MariaDB, которые пытаются показать разницу между MariaDB и MySQL, а н... весь текст скрыт [показать]
     
  • 3.25, Andrey Mitrofanov, 10:07, 23/10/2015 [^] [ответить] [смотреть все]  
  • +8 +/
    > а где
    > ща phoronix-у накатаю телегу ...

    Как любит повторять Ларабель, "где-где, в премиум акаунтах".

     
  • 2.6, parad, 01:44, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –19 +/
    где std::map, std::unordered_map?
     
     
  • 3.7, parad, 01:48, 23/10/2015 [^] [ответить] [смотреть все]  
  • –19 +/
    притом я вполне серьездно 64гб 10 6 64к на запись - что врятли короче это хе... весь текст скрыт [показать]
     
     
  • 4.20, Аноним, 09:23, 23/10/2015 [^] [ответить] [смотреть все]  
  • –15 +/
    innodb buffer pool size 512M для тестов его обычно берут с запасом, но не в эт... весь текст скрыт [показать]
     
     
  • 5.29, parad, 11:17, 23/10/2015 [^] [ответить] [смотреть все]  
  • –16 +/
    512 байт/запись + кеш фс. тут как не крути тест кривой.
     
  • 2.30, Alex, 11:57, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –18 +/
    В заднице.
    Извините.
     
  • 1.3, chaos_dremel, 00:48, 23/10/2015 [ответить] [смотреть все]  
  • –13 +/
    Percona Server где?
     
     
  • 2.9, Аноним, 02:14, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • +10 +/
    Дабы не огорчать любителей мускула и мариядб перкону решили не включать в тест.
     
     
  • 3.36, ., 16:25, 23/10/2015 [^] [ответить] [смотреть все]  
  • –10 +/
    Чтобы не огорчать Нуловимого Индейца Джо ... его не стали звать на вечеринку.
     
     
  • 4.38, Анончег, 23:59, 23/10/2015 [^] [ответить] [смотреть все]  
  • –6 +/
    Поддержал. Кака така персона?
     
  • 1.5, fi, 00:58, 23/10/2015 [ответить] [смотреть все]  
  • +4 +/
    Упс! а как же в предыдущей новости: «Проведена оптимизация производительности. В тесте SysBench при установке 1024 соединений MySQL 5.7 сумел продемонстрировать производительность в 1.6 млн запросов на чтение в секунду, что в три раза выше, чем смогла обеспечить конфигурация на основе MySQL 5.6.» ???


     
     
  • 2.14, _KUL, 06:31, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –5 +/
    Вот вот, прям как в поговорке каждый тестит так как хочет Нужен объективный т... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.19, Аноним, 08:58, 23/10/2015 [^] [ответить] [смотреть все]  
  • –7 +/
    > Нужен объективный тест от конторы сторонней.

    Похороникс?

     
  • 2.23, Аноним, 09:47, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –4 +/
    http dimitrik free fr Presentations MySQL_Perf-Benchmarks-PLive_AMS-Sep 2015-d... весь текст скрыт [показать] [показать ветку]
     
  • 1.8, Просто, 02:03, 23/10/2015 [ответить] [смотреть все]  
  • –6 +/
    Наш ответ "Чемберлену" от команды MariaDB :)
     
  • 1.10, Аноним, 02:42, 23/10/2015 [ответить] [смотреть все]  
  • –8 +/
    Теплые ламповые тесты фороникс'а?
     
  • 1.11, Anonplus, 04:46, 23/10/2015 [ответить] [смотреть все]  
  • +3 +/
    То есть, и оракл и разработчики форка, ухудшили производительность продукта? Разница лишь в том, что MariaDB скатилась не так сильно. Я правильно понимаю? Если да, то ни тем, ни другим гордиться нечем.
     
     
  • 2.17, Аноним, 07:40, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • +8 +/
    А куда деваться?
    База данных это много операций с памятью. Модификация этих структур должна быть атомарна (возможность менять несколько полей и не получать частичные изменения от других потоков).
    Значит нужны мьютексы или хитрые lock-free алгоритмы (которые приводят к увеличению использования памяти и мы теряем процессорный кеш).

    Если мьютексов мало, то производительность на 1-4 потоках выше.
    Барьеры дорогое удовольствие: http://kristiannielsen.livejournal.com/17598.html

    Обратно, если мы исполняем одновременно сотни или тысячи потоков, то один горячий мьютекс сводит производительность на нет (например в mysql 4.1 или старых посгресах): работают 1-2 ядра процессора, остальные не используются. Как чинить такие проблемы? Разбивать мьютексы не несколько: вместо одной большой структуры делаем десяток структур, самые горячие структуры защищаем отдельными мьютексами. Например вместо одной точки выдачи новых значений auto_increment делаем несколько генераторов нового значения с разным смещением (offset).

    Приходим к тому что новое решение может использовать современные процессоры.
    В обычные 2U влезает 2-4 сокета, Intel предлагает процессоры с 12ти ядрами, amd с 16ти.
    Итого получаем 48-64 честных ядра и 96 с гипертредингом, который с ростом количества ядер становится более эфективным.

    Значит горячие мьютексы из mysql 4.1 надо размножить минимум в 100 раз чтобы максимально эфективно использовать дешёвое серверное железо. Если брать дорогое железо (те же power, на которых MariaDB показывала 1 миллион запросов в testbench, содержат до 1024 потоков на исполнение).

    Итого, даже если производительность одного потока будет в 3 раза меньше, за счёт 100 ядер процессора мы получим в 30 большую производительность на современном железе, чем мы имели на старых версиях mysql/postgresql

     
     
  • 3.28, psrafo, 10:57, 23/10/2015 [^] [ответить] [смотреть все]  
  • –3 +/
    Да спасибо
     
  • 1.12, Аноним, 05:23, 23/10/2015 [ответить] [смотреть все]  
  • +9 +/
    http://dimitrik.free.fr/blog/archives/2015/04/mysql-performance-pushing-yet-m

    Какой прикольный тест на специально выбранном железе.
    5.7 показывает на 64 ядрах пятикратный рост производительности, 5.6 утыкается на 32 тредах (как и форкнутый на 5.5 mariadb).

    А mariadb в прес релизе берёт 4 ядра (на каком серваке выпущенном в этом году будет 4 ядра?)

    Не, ну а что можно взять 1 ядро и 5.0 обгонит и mariadb и 5.7
    http://www.fromdual.com/mysql-single-query-performance-the-truth

     
     
  • 2.22, Аноним, 09:41, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –9 +/
    ой да ладно, какой-нибйдь define поменяли с define POOL_MAX_THREADS 32 на defi... весь текст скрыт [показать] [показать ветку]
     
  • 1.13, Тот_Самый_Анонимус, 05:47, 23/10/2015 [ответить] [смотреть все]  
  • +9 +/
    >Разработчики MariaDB провели тестирование производительности
    >а наихудшие - MySQL 5.7.9

    Ну кто бы сомневался...

     
  • 1.16, Fracta1L, 07:09, 23/10/2015 [ответить] [смотреть все]  
  • +6 +/
    И это поделие пихают во все дистрибутивы.
     
  • 1.21, Аноним, 09:26, 23/10/2015 [ответить] [смотреть все]  
  • +5 +/
    Clipper где?!
     
     
  • 2.24, 1, 09:53, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • +11 +/
    И FoxBase не протестили, лентяи.
     
  • 2.31, анонимус, 12:48, 23/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –9 +/
    Там же где dbase и Clarion :)
     
     
  • 3.35, Антон, 14:53, 23/10/2015 [^] [ответить] [смотреть все]  
  • +7 +/
    эээ....Clarion наше все :)
     
     
  • 4.37, ., 16:39, 23/10/2015 [^] [ответить] [смотреть все]  
  • –8 +/
    Это просто огромное счастье что Clarion,Clipper и прочее - всё ВАШЕ Я по нем - ... весь текст скрыт [показать]
     
  • 1.32, Аноним, 13:24, 23/10/2015 [ответить] [смотреть все]  
  • –5 +/
    На базе каких версий мускуля сделаны эти версии мариды?
     
  • 1.33, Аноним, 13:58, 23/10/2015 [ответить] [смотреть все]  
  • +6 +/
    MariaDB сдулась, и сайт у них заброшен уже несколько лет, в особенности доки. Надо с Percona сравнивать, это единственный форк, над которым сейчас работают и делают что-то серьезное, а не бирюльки.
     
  • 1.34, Аноним, 13:59, 23/10/2015 [ответить] [смотреть все]  
  • +8 +/
    MariaDB как ubuntu, тупо компонует чужие наработки.
     
     
  • 2.62, Аноним, 21:49, 24/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    lolwut Оптимизатор подзапросов первым где был сделан Hash joins где были сделан... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.63, Аноним, 21:52, 24/10/2015 [^] [ответить] [смотреть все]  
  • +/
    Virtual columns, кстати, в оракле скоммуниздили с марии, после чего поменяли син... весь текст скрыт [показать]
     
  • 2.64, vovans, 14:53, 26/10/2015 [^] [ответить] [смотреть все] [показать ветку]  
  • –1 +/
    эх, жаль, минусовать не могу
     
  • 1.65, Аноним, 13:06, 06/02/2016 [ответить] [смотреть все]  
  • +/
    а-ля-ля
     

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


      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor