| |
| 2.4, asavah (ok), 00:58, 23/10/2015 [^] [^^] [^^^] [ответить]
| –20 +/– |
 а где firebird, oracle, mssql, sqlite, sybase, db2 ...
ща phoronix-у накатаю телегу ...
| | |
| |
| 3.15, eRIC (ok), 07:01, 23/10/2015 [^] [^^] [^^^] [ответить]
| –16 +/– |
 >а где firebird, oracle, mssql, sqlite, sybase, db2 ...
это авторы MariaDB, которые пытаются показать разницу между MariaDB и MySQL, а не полное сравнение всех СУБД на планете...
| | |
|
| |
| 3.7, parad (ok), 01:48, 23/10/2015 [^] [^^] [^^^] [ответить]
| –19 +/– |
 притом я вполне серьездно: 64гб/10^6 = 64к на запись - что врятли. короче это херня а не тест.
| | |
| |
| 4.20, Аноним (-), 09:23, 23/10/2015 [^] [^^] [^^^] [ответить]
| –15 +/– |
innodb buffer pool size = 512M
для тестов его обычно берут с запасом, но не в этом случае sysbench oltp тест на миллион строк это где-то 550-600МБ на диске.
| | |
| |
| 5.29, parad (ok), 11:17, 23/10/2015 [^] [^^] [^^^] [ответить]
| –16 +/– |
512 байт/запись + кеш фс. тут как не крути тест кривой.
| | |
|
|
|
|
| |
| 2.9, Аноним (-), 02:14, 23/10/2015 [^] [^^] [^^^] [ответить]
| +10 +/– |
Дабы не огорчать любителей мускула и мариядб перкону решили не включать в тест.
| | |
| |
| 3.36, . (?), 16:25, 23/10/2015 [^] [^^] [^^^] [ответить]
| –10 +/– |
Чтобы не огорчать Нуловимого Индейца Джо ... его не стали звать на вечеринку.
| | |
|
|
| 1.5, fi (ok), 00:58, 23/10/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 Упс! а как же в предыдущей новости: «Проведена оптимизация производительности. В тесте SysBench при установке 1024 соединений MySQL 5.7 сумел продемонстрировать производительность в 1.6 млн запросов на чтение в секунду, что в три раза выше, чем смогла обеспечить конфигурация на основе MySQL 5.6.» ???
| | |
| |
| 2.14, _KUL (ok), 06:31, 23/10/2015 [^] [^^] [^^^] [ответить]
| –5 +/– |
 Вот вот, прям как в поговорке "каждый тестит так как хочет". Нужен объективный тест от конторы сторонней.
| | |
|
| 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
| | |
|
| |
| 2.22, Аноним (-), 09:41, 23/10/2015 [^] [^^] [^^^] [ответить]
| –9 +/– | |
> 5.7 показывает на 64 ядрах пятикратный рост производительности, 5.6 утыкается на 32 тредах (как и форкнутый на 5.5 mariadb).
ой да ладно, какой-нибйдь define поменяли с #define POOL_MAX_THREADS 32 на #define POOL_MAX_THREADS 64
| | |
|
| |
| |
| |
| 4.37, . (?), 16:39, 23/10/2015 [^] [^^] [^^^] [ответить]
| –8 +/– |
Это просто огромное счастье что Clarion,Clipper и прочее - всё ВАШЕ. Я по нем - не соскучился :)
| | |
|
|
|
| 1.33, Аноним (-), 13:58, 23/10/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
MariaDB сдулась, и сайт у них заброшен уже несколько лет, в особенности доки. Надо с Percona сравнивать, это единственный форк, над которым сейчас работают и делают что-то серьезное, а не бирюльки.
| | |
| |
| 2.62, Аноним (-), 21:49, 24/10/2015 [^] [^^] [^^^] [ответить]
| +/– | |
lolwut
Оптимизатор подзапросов первым где был сделан? Hash joins где были сделаны? Virtual columns где были сделаны?
| | |
| |
| 3.63, Аноним (-), 21:52, 24/10/2015 [^] [^^] [^^^] [ответить]
| +/– |
Virtual columns, кстати, в оракле скоммуниздили с марии, после чего поменяли синтаксис - явно умышленно, для несовместимости: семантически и технически между мариевским persistent и оракловым stored нет никакой разницы.
| | |
|
|
|
