Зависит ли производительность базы данных в памяти от того, написана ли она на C++ или Java
Мы пытаемся найти базу данных в памяти с поддержкой индекса, которую мы можем использовать для нашего приложения. Мы смотрим на Aerospike, Apache Ignite, Geode, Voltdb. Различать особо нечего, и все утверждают, что они быстрые и пользуются большой поддержкой сообщества.
Из них Aerospike и VoltDB основаны на C/C++, а Apache Ignite и Geode основаны на java.
Учитывая, что выбирать между базами данных с точки зрения производительности мало, и, кроме того, сложно проверить, какая база данных будет работать для нас лучше в производственной среде, пытался выяснить, будет ли производительность базы данных в памяти также зависеть от того, на основе Java или C/C++. Учитывая, что проблемы со сборкой мусора встречаются довольно часто, и трудно правильно настроить их для вашего варианта использования (который может измениться через некоторое время), правда ли, что базы данных на основе Java будут в невыгодном положении.
Спасибо
3 ответа
Вы не можете сделать вывод, что один дб быстрее другого, потому что он написан на языке X против языка Y. База данных - очень сложный продукт с множеством функций. Некоторые запросы могут быть быстрее в одном БД, другие запросы в другом БД.
Единственный способ выяснить это - проверить ваш конкретный вариант использования.
Я думаю, что я собираюсь быть противоположным.
При прочих равных скомпилированный код работает быстрее, чем JVM, и просто не требуется сборщик мусора, чтобы избежать тактики.
Будучи написанным на C/C++, eXtremeDB (продукт моей компании) может полностью отказаться от управления памятью на C. Полное управление областью памяти в программном обеспечении базы данных позволяет использовать высокоэффективные и специализированные менеджеры памяти и устраняет возможность утечек памяти (с точки зрения всей системы, например, если 200 ГБ выделено для базы данных в памяти, это никогда не будет превышать 200 ГБ). eXtremeDB не уникален в этом отношении; другие СУБД в памяти, написанные на C / C++, также способны избегать выполнения C malloc/free или C++ new/delete. Так что, пожалуйста, не звоните мне за создание продукта, я не. Я указываю на возможность, которая возможна в реализации C / C++, которая может быть недоступна в JVM.
Другие ответчики правы: дрянная реализация плана выполнения SQL для данного запроса может сокрушить любое преимущество скомпилированного кода перед JVM, но в какой-то момент вы должны быть уверены, что ваш поставщик СУБД знает, что они делают (и заинтересованы в улучшении своего продукта, если план явно неэффективен / неправильный). Если вы не используете SQL, то плюсы и минусы оптимизатора SQL не являются частью уравнения, и в действительности все зависит от того, насколько хорошо написаны методы индексации системы базы данных, и от наличия разных типов индексов для разных поисковых запросов. (например, хеш-индекс, как правило, будет лучше, чем b-дерево для точного поиска соответствия, но хеш-индекс не может поддерживать поиск по частичному ключу (подстановочный знак) или упорядоченный поиск).
Есть некоторые публичные (независимые, проверенные) тесты, на которые вы можете посмотреть. Мы участвовали в нескольких STAC-M3, хотя также есть только в одной другой СУБД (СУБД, которую вы указали специально, нет).
Для БД в памяти, которая поддерживает согласованность, как это делает Geode (то есть выполняет синхронную репликацию на другие узлы перед освобождением клиентского потока), ваша сеть будет более серьезной проблемой, чем компилятор горячей точки. Тем не менее, здесь есть две точки ввода, чтобы вы пришли к точке, где язык не имеет значения:
1) Если вы выполняете много операций создания / обновления поверх операций чтения: используйте память вне кучи на сервере. Это сводит к минимуму GC.
2) Используйте отображение сериализации Geode между объектами C/C++ и Java, чтобы избежать JNI. В частности, используйте DataSerializer http://gemfire.docs.pivotal.io/geode/developing/data_serialization/gemfire_data_serialization.html Если вы планируете использовать запросы чаще, чем получает / помещает, используйте PDXSerializer: http://gemfire.docs.pivotal.io/geode/developing/data_serialization/use_pdx_serializer.html