в настоящее время мы работаем на грани ресурсов с нашим решением на основе сервера mssql.
Теперь у нас есть много традиционных вариантов следующего шага для решения проблемы:
- купить быстрее процессоры и IO
- разделить несколько клиентов на отдельный сервер
- переместить базу данных в кластер
Все это дорого с точки зрения лицензирования и оборудования или времени. Итак, я хочу добавить еще одну опцию, переместив всю систему в масштабируемое решение, которое обещает nosql engine cassandra.
Тем не менее, я не уверен и не имею опыта работы с базами данных noSQL, поэтому мне нужно понять структуру «неструктурированных» данных.
В нашем приложении мы в основном храним данные, введенные пользователями различными способами, в виде списков «ключ-значение». Существует родительская таблица, которая содержит элемент head (например, Order), а также дочерняя таблица с парами ключ-значение, составляющими содержимое заказа (например, Order_Lines).
С точки зрения бизнеса, Order и OrderLines являются единым целым. Но благодаря РСУБД они хранятся в таблицах и должны быть все время объединены.
Во время операций мы иногда выбираем загрузку только верхней части, но в большинстве случаев мы загружаем ряд заголовков + некоторые KVP, чтобы отобразить некоторую полезную информацию.
Например, в обзорном списке мы показываем идентификатор головы + некоторые значения в столбцах для каждой строки.
ОБНОВЛЕНИЕ: Мы храним любые формы. Итак, в основном мы храним «документы». Тем не менее, мы должны подготовить и выполнить поиск по этим формам по любому значению, сортировке и т. Д. Контроль доступа к данным добавляет еще один уровень сложности в базу данных.
Как вы можете догадаться, количество и доступность определенных KVP варьируется от объекта к объекту. Не существует действительной возможности для создания отдельных таблиц для каждого типа объектов, поскольку нам пришлось бы создавать тысячи таблиц для различных комбинаций данных.
Будет ли этот тип «словаря», как наборы данных, лучше храниться в базе данных noSQL? И получим ли мы от этого преимущества в производительности? Будет ли Кассандра моделировать эти головы + KVP как один набор данных? Глядя на веб-страницу cassandra и некоторые учебные пособия, у меня сложилось впечатление, что между нашими RDBMS и cassandra не так много различий с точки зрения организации данных - у нас остается такое же огромное количество объединений, если вы хотите выбрать 5 KVP. для списка для каждой строки.
Просвещение приветствуется, также есть ссылки на документы, объясняющие проблемы, в порядке.