зависит ли производительность базы данных в памяти от того, написана ли она на c++ или java

Вы не можете сделать вывод, что одна база данных быстрее другой только потому, что она написана на языке X, а не на языке Y. База данных — очень сложный продукт с множеством функций. Некоторые запросы могут быть быстрее в одной БД, другие запросы в другой БД.

Единственный способ узнать это — протестировать ваш конкретный вариант использования.

Для БД в памяти, которая поддерживает согласованность, как это делает Geode (т. е. выполняет синхронную репликацию на другие узлы перед выпуском клиентского потока), ваша сеть будет более серьезной проблемой, чем компилятор точки доступа. Тем не менее, вот две точки ввода, которые помогут вам понять, где язык не имеет значения:

1) Если вы делаете много операций создания/обновления поверх чтения: используйте память вне кучи на сервере. Это сводит к минимуму GC.

2) Используйте сопоставление сериализации Geode между объектами C/C++ и Java, чтобы избежать JNI. В частности, используйте DataSerializer http://gemfire.docs.pivotal.io/geode/developing/data_serialization/gemfire_data_serialization.html Если вы планируете широко использовать запросы, а не get/puts, используйте PDXSerializer: http://gemfire.docs.pivotal.io/geode/development/data_serialization/use_pdx_serializer.html

Я предполагаю, что я собираюсь быть противоположным.

При прочих равных, скомпилированный код работает быстрее, чем JVM, и просто нет необходимости использовать сборку мусора, чтобы избежать тактики.

Будучи написанным на C/C++, eXtremeDB (продукт моей компании) может полностью избежать использования управления памятью во время выполнения C. Полное управление областью памяти в программном обеспечении базы данных позволяет использовать высокоэффективные и специализированные менеджеры памяти и устраняет возможность утечек памяти (с точки зрения всей системы, например, если 200 ГБ отведено для базы данных в памяти). , он никогда не превысит 200 ГБ). eXtremeDB не уникальна в этом отношении; другие СУБД с оперативной памятью, написанные на C/C++, также могут избежать операций malloc/free во время выполнения C или new/delete C++. Так что, пожалуйста, не обвиняйте меня в том, что я делаю презентацию продукта, это не так. Я указываю на возможность, которая возможна с реализацией C/C++, но может быть недоступна с JVM.

Другие ответчики правы: дрянная реализация плана выполнения SQL для данного запроса может свести на нет любое преимущество скомпилированного кода по сравнению с JVM, но в какой-то момент вы должны быть уверены, что ваш поставщик СУБД знает, что они делают ( и заинтересованы в улучшении своего продукта, если план явно неэффективен/неправилен). Если вы не используете SQL, то качество/плохость оптимизатора SQL не является частью уравнения, и на самом деле это зависит от того, насколько хорошо написаны методы индексирования системы баз данных, а также от наличия различных типов индексов для различных требований поиска. (например, хэш-индекс, как правило, лучше, чем b-дерево, для поиска с точным соответствием, но хэш-индекс не может поддерживать поиск с частичным ключом (шаблоном) или упорядоченный поиск).

Есть несколько общедоступных (независимых, проверенных) тестов, на которые вы можете обратить внимание. Мы участвовали в нескольких STAC-M3, хотя только одна другая СУБД также участвовала (в частности, СУБД, которую вы перечислили, не участвовала).