Быстрее и быстрее, это то, что мы хотим от наших баз данных. И самым большим препятствием для MySQL Dragster является скорость жесткого диска, верно? Нет, я не собираюсь это обсуждать, это как раз тот случай. И как ты тогда это исправишь? Что ж, если то, что ограничивает вашего драгстера, является препятствием, то либо вы проезжаете через него, либо исчезаете быстрее, либо в терминах компьютера:
- Избегайте использования диска, вместо этого поместите как можно больше данных в оперативную память
- Используйте более быстрые диски (например, SSD)
Теперь, если честно, эта аналогия не так хороша, потому что фактор ограничения производительности диска настолько велик, и вопреки распространенному мнению, он не становится лучше! Но у нас есть твердотельные накопители, говорите? Да, это делает жесткий диск быстрее, но процессор и оперативная память становятся еще быстрее! Но давайте предположим, что у нас достаточно памяти, поэтому нам не нужен диск? Будет ли все идти со скоростью света? Нет, то, что происходит здесь, это то, что даже не было заметно с точки зрения ограничения производительности, когда диск был там, так как дисковый ввод-вывод — такое огромное узкое место, внезапно показывает, что это грязное лицо!
Примерно так: поскольку ядра ЦП становятся быстрее, но не намного быстрее, из-за физических ограничений, у нас все больше и больше этих ядер ЦП. И вдруг любое ограничение в том, чтобы заставить эти процессоры хорошо работать вместе, внезапно превращается в большую головную боль! Как мьютекс, разделяемый всеми потоками. Как, например, мьютекс Query Cache в MySQL!
Имея это в виду, я теперь готов начать с ориентиров, о которых я
писал в мае, Да, потребовалось некоторое время, чтобы загрузить данные в MySQL, и в процессе мне удалось создать новый проект с открытым исходным кодом для экспорта и импорта данных JSON из и в MySQL. Теперь у меня есть нечто вроде реальных данных. Мне пришлось удалить несколько столбцов (или Атрибуты вас — талибы JSON), чтобы заставить MySQL Cluster работать с этими данными, потому что MySQL Cluster хранит данные VARCHAR как данные фиксированной длины на диске, что означает несколько вещей:
- На диск записывается намного больше материала.
- UTF-8 означает, что в 3 раза больше данных для записи!
Все это означает, что MySQL Cluster может хорошо работать в качестве альтернативы некоторым настройкам хранилища ключей-значений, но не всем, и это зависит от того, что означает здесь «значение». Если «значение» означает «документ» или «объект», то нам нужно использовать VARCHAR или что-то подобное для значения, что будет реальным ограничением в случае MySQL Cluster. И я постараюсь быть очень милым с MySQL Cluster здесь, поэтому я получаю действительно простую схему:
CREATE TABLE `keyvalue` ( `id` bigint(20) NOT NULL, `value1` int(11) DEFAULT NULL, `value2` double DEFAULT NULL, PRIMARY KEY (`id`) )
И в этой таблице я загружаю около 105.000.000 строк. Должно быть просто с MySQL Cluster, верно? За исключением того, что MySQL Cluster будет размещать только 512 Мб хеш-данных на раздел (это действительно, очень глупое ограничение! Разве 512 Мб версии MySQL Cluster «640 K должно хватить для всех?»). Но это поправимо, и с 4 разделами это работает просто отлично.
Как примечание: без данных на диске MySQL Cluster чувствует себя НАМНОГО более стабильным. Случайная потеря данных и другие странности, с которыми я столкнулся при попытке загрузить таблицу с данными VARCHAR, теперь полностью исчезли. Таким образом, данные на диске не только ограничивают вас с точки зрения типов данных (VARCHAR), но и требуют дополнительной разработки. И нет, я не был в настроении воспроизводить ошибки, которые я получил.
Во всяком случае, на моем сервере здесь, дома, с 8-ядерным процессором AMD и 16 Гб оперативной памяти, ожидающих запуска этого теста. Я тестирую MySQL с InnoDB, MySQL Cluster и MongoDB. Программа тестирования одинакова во всех случаях, я прочитал 1.000.000 строк, 10 раз распределенных по 100 потокам. Чтобы быть справедливым для всех, я позаботился о том, чтобы данные, которые у меня были, поместились в память и были в памяти, поэтому сначала я выполнил несколько прогонов прогона. В случае NDB я использовал MySQL API, а не NDBAPI (я попробую это в конце концов). Я получил следующие результаты:
- MongoDB — 110 000 операций чтения в секунду
- MySQL с InnoDB — 30 000 операций чтения в секунду
- MySQL с NDB — 32 000 операций чтения в секунду
В случае с NDB у меня были эти настройки, помимо стандартных вещей:
ndb_use_exact_count=0 ndb_force_send=0
И это имеет огромное значение, я могу сказать вам это! Почему это не по умолчанию, я не знаю, я полагаю, что для этого есть веская причина, но кто-то должен сказать мне, что это такое. Теперь я также загрузил данные, и результаты там были схожими, но поскольку я загружал JSON, и это довольно родное для MongoDB, как и ожидалось, MongoDB был примерно в 2,5 раза быстрее, чем NDB / InnoDB, которые были на одном уровне с каждым разное. Я не буду здесь приводить точные цифры, поскольку загрузка данных зависит от гораздо большего в плане настройки.
Это не конец этой истории, хотя, если предположить, поскольку MySQL отставал от MongoDB с точки зрения производительности, но InnoDB и NDB были на одном уровне с другими, можно, по крайней мере, попробовать теорию, что это часть MySQL это замедляет работу, и это можно проверить, запустив MySQL / NDB с более чем одним mysqld, и это следующая попытка. Тогда у нас есть интерфейс HANDLER и правильный NDBAPI, последний должен быть намного быстрее, правда. И да, я действительно должен увидеть, что MyISAM может сделать для меня. И MariaDB.
И прежде чем закончить, пожалуйста, разработчики MySQL Cluster, удалите это глупое ограничение размера HASH индекса 512 МБ на раздел (см. Руководство здесь). Поскольку оперативная память становится все менее и менее дорогой, и если мы, например, хотели бы максимально избежать сетевого и дискового ввода-вывода и вместо этого использовать оперативную память и ЦП (как в среде Amazon), то это превращается в довольно серьезное ограничение. Мои тесты выше были на твердом железе, хотя.