Примечание редактора: эта статья была изначально написана Эндрю Уилсоном из блога VoltDB.
Базы данных NewSQL и NoSQL предоставляют разработчикам новую и интересную модель программирования, в которой меньше соединений с базой данных, параллелизм запросов, разделы и простая модель для поддержки новых кластеров. В прошлом месяце я представил вебинар, знакомящий с основами разработки приложений с использованием VoltDB. У нас было много замечательных вопросов, и я подумал, что будет полезно написать их и поделиться ответами со всеми.
Вопрос: Можете ли вы указать, как вы будете обрабатывать таблицы, которые имеют разные ключи разделов? Разве вы не разбили бы таблицы в этом случае?
A: Для многораздельных запросов вы объединяете реплицированные таблицы и многораздельные таблицы, и вы можете объединять две или более многораздельных таблиц, но они должны объединяться по ключу секционирования всей таблицы.
Если в запросе есть предложение where, ограничивающее запрос одним разделом, его можно выполнить как запрос одного раздела. Для запросов с одним разделом вы можете объединить любую комбинацию реплицированных и разделенных таблиц.
Во всех случаях рассмотрите возможность объединения столбцов, поддерживаемых индексами (чтобы они были быстрыми).
При объединении таблиц в общем смысле необходимо учитывать ряд факторов. Должна ли таблица быть реплицированной, то есть локальной для каждого раздела, или она слишком велика? Например, у меня может быть таблица «пользователи», которая содержит тысячи пользователей. Возможно, мне потребуется сопоставить этих пользователей с ролью, и в этой таблице «ролей» может быть только семь или восемь ролей. В этом случае безопасно разделить таблицу «users» и реплицировать таблицу «role».
Подумайте, если ваша таблица «пользователи» соединяется с таблицей «заказов». Эта таблица «заказов» может иметь тысячи или миллионы строк, что делает ее плохим кандидатом для репликации. Кроме того, из-за бизнес-правил может возникнуть необходимость разделить заказы на что-либо, кроме пользователя, а не на идентификатор заказа. Объединение в этом случае приведет к многораздельному запросу.
Вопрос: При написании оператора SQL выбора VoltDB, который использует неуникальный индекс, нужно ли включать все выбранные столбцы в предложение ORDER BY, чтобы гарантировать детерминированное поведение?
О: Обычно это так, поскольку неуникальный индекс не гарантирует относительного упорядочения записей с дублированными индексированными столбцами и различными неиндексированными столбцами. Однако если ВСЕ выбранные столбцы являются индексированными столбцами в выбранном индексе, столбцы не нужно включать в предложение ORDER BY.
Если есть другие (неиндексированные) столбцы, предложение ORDER BY должно включать все выбранные столбцы.
Для уникального индекса значения любых других столбцов будут полностью определяться порядком индексированного столбца.
Q: PostgreSQL имеет тип ячейки ARRAY [], который мы широко используем. У VoltDB есть что-то подобное?
A: На самом деле не существует сопоставимого типа без использования собственных пользовательских механизмов сериализации. Мы выпускаем новый тип столбца JSON в будущей редакции, и JSON поддерживает поля массива. Вы также можете передавать массивы в хранимые процедуры, поэтому использование нового типа JSON или настраиваемого сериализатора может стать для вас вариантом.
Вопрос: совместимы ли хранимые процедуры Java с хранимыми процедурами Oracle? Если нет, знаете ли вы, как управлять миграцией?
A: Они не совместимы. Мы используем ряд специфичных для VoltDB классов Java и, следовательно, не можем запускать существующие хранимые процедуры Oracle Java.
Управление миграцией, независимо от исходной БД, немного сложнее и зависит от вашего расписания. В лучшем случае я бы рекомендовал сначала пересмотреть процедуры, чтобы понять, какие из них имеют смысл перейти на VoltDB. Вы можете обнаружить, что одну или несколько хранимых процедур можно объединить в одну хранимую процедуру. Затем я построю модульные тесты для процедур Oracle Oracle с использованием известного набора данных, а затем создаю хранимые процедуры VoltDB и проверяю их с помощью модульных тестов.
Вопрос: Можно ли использовать CDC (сбор данных изменений) для репликации данных VolDB в базу данных Analytics? Если нет, каковы альтернативы?
A:Существует несколько стратегий, которые пользователи VoltDB используют для передачи данных в аналитические базы данных. Во-первых, использовать функциональность таблицы экспорта VoltDB. Таблицы экспорта действуют как постоянные очереди — вы можете добавлять к ним данные с помощью SQL, а внешний клиент опрашивает эти данные по хорошо опубликованному протоколу. Этот внешний «экспортный» клиент извлекает данные и доставляет их в целевую внешнюю систему, проверяя получение данных (и, таким образом, удаляя их из таблицы экспорта VoltDB). VoltDB поддерживает (и поставляет) клиента экспорта плоских файлов, клиента PostgreSQL, а также клиента экспорта Hadoop из коробки. Разработка новых экспортных клиентов — довольно простая задача. Для получения дополнительной информации о функции экспорта VoltDB, пожалуйста, смотрите: http://voltdb.com/company/blog/voltdb-export-connecting-voltdb-other-systems
Другие более традиционные стратегии CDC, такие как временные метки строк или версионирование строк, легко реализовать в VoltDB на прикладном уровне, добавив соответствующие столбцы в таблицы. Внутренняя временная метка на строку отсутствует, например, в VoltDB.
Q: Размер базы данных ограничен размером доступной оперативной памяти? Как управлять виртуальной памятью?
A: Размер базы данных ограничен объемом памяти в кластере. Мы предлагаем пользователям отключить обмен, чтобы избежать непреднамеренного снижения производительности.
Обратите внимание, что виртуализированные машины часто не позволяют отключить подкачку или подкачка скрыта от гостевой ОС. В любом случае рекомендуется проводить тестирование пропускной способности, так как могут вступить в действие другие факторы, которые могут отрицательно повлиять на пропускную способность и задержку, например, качество сети и дисков, если вы используете снимки или протоколирование команд.
Вопрос: Какова самая большая реализация с точки зрения количества таблиц?
О: По всему миру развернуты сотни приложений VoltDB. Хотя у нас нет точного количества таблиц для этих приложений, нам известны реализации в диапазоне от 100 до 200. Кроме того, у нас есть клиенты, развертывающие приложения на более чем 30 узлах как на голом железе, так и в облаке Amazon.
Q: Привет — нам нравится делать все наши сборки с Maven. Вы поддерживаете это?
О: Да, мы работаем с Maven, но наши библиотеки не находятся в центральном хранилище. Обычно вам нужно вручную добавить две библиотеки. Первая — это клиентская библиотека, если вы работаете на стороне клиента, и библиотека хранимых процедур, если вы работаете на стороне сервера. Следующие операторы импорта maven являются примерами того, что я использовал в VoltDB 2.8.2:
mvn install:install-file -Dfile=./voltdb-2.8.2.jar -DgroupId=org.voltdb -DartifactId=VoltDB -Dversion=2.8.2 -Dpackaging=jar
mvn install:install-file -Dfile=./voltdbclient-2.8.2.jar -DgroupId=org.voltdb -DartifactId=VoltDBclient -Dversion=2.8.2 -Dpackaging=jar
В: Есть ли какой-нибудь рекомендуемый способ сохранить порядок развития схемы БД (IE как набор «патчей»)? Спасибо
A: VoltDB поддерживает обновления каталога, где вы можете добавлять и удалять таблицы. Вы также можете добавлять, удалять и обновлять хранимые процедуры. В ближайшие недели мы добавим дополнительную поддержку для изменений схемы в сети, таких как добавление / удаление индексов и столбцов.
Q: Насколько хорошо гели VoltDB с гибернацией / mybatis или другими основанными на Java средами персистентности?
A: В настоящее время мы не поддерживаем Hibernate или MyBatis напрямую.
Вопрос: Вы упомянули об ограничении 50 МБ для набора результатов запроса. Означает ли это, что разработчик должен заранее определить размер набора результатов запроса и не использовать его?
О: Да, вы должны быть уверены, что ваш набор результатов меньше 50 МБ, иначе запрос или хранимая процедура завершатся неудачно.
Вопрос: VoltDB описывается как база данных в памяти, но чем она отличается от загрузки полной базы данных Oracle в память?
A: Мы значительно быстрее, чем Oracle в памяти. Исследования в Массачусетском технологическом институте, Брауне и Йельском университете выявили, что более 90% обработки в традиционных базах данных можно классифицировать как «накладные расходы», оставляя скудные 7% обработки фактической «работе». Эти накладные расходы включают в себя такие вещи, как управление буфером, блокировка, фиксация и ведение журнала. VoltDB был спроектирован с нуля, чтобы устранить эти издержки, находясь в оперативной памяти, тем самым устраняя буферизацию, и выполнять каждую транзакцию параллельно и изолированно, тем самым устраняя необходимость фиксировать или блокировать. Когда традиционные базы данных работают в памяти, они все еще несут традиционные накладные расходы или багаж.
Для получения дополнительной информации об инновационной архитектуре и вычислительной мощности VoltDB, пожалуйста, обратитесь к следующим исследовательским работам:
- Конец архитектурной эры: (пора полностью переписать): http://hstore.cs.brown.edu/papers/hstore-endofera.pdf
- OLTP через зеркало и то, что мы нашли там http://hstore.cs.brown.edu/papers/hstore-lookingglass.pdf
Спасибо всем, кто настроился, и особенно тем, кто прислал несколько замечательных вопросов. Не забудьте проверить раздел форумов на нашем сайте сообщества для получения дополнительной информации. Пожалуйста , присоединяйтесь к нам на следующей неделе , когда я буду представлять наш следующий вебинар «Написание VoltDB Apps в NodeJS» на 11 октября — го .