NoSQL: что такое неструктурированные данные?

в настоящее время мы работаем на грани ресурсов с нашим решением на основе сервера mssql.

Теперь у нас есть много традиционных вариантов следующего шага для решения проблемы:

• купить быстрее процессоры и IO
• разделить несколько клиентов на отдельный сервер
• переместить базу данных в кластер

Все это дорого с точки зрения лицензирования и оборудования или времени. Итак, я хочу добавить еще одну опцию, переместив всю систему в масштабируемое решение, которое обещает nosql engine cassandra.

Тем не менее, я не уверен и не имею опыта работы с базами данных noSQL, поэтому мне нужно понять структуру «неструктурированных» данных.

В нашем приложении мы в основном храним данные, введенные пользователями различными способами, в виде списков «ключ-значение». Существует родительская таблица, которая содержит элемент head (например, Order), а также дочерняя таблица с парами ключ-значение, составляющими содержимое заказа (например, Order_Lines).

С точки зрения бизнеса, Order и OrderLines являются единым целым. Но благодаря РСУБД они хранятся в таблицах и должны быть все время объединены.

Во время операций мы иногда выбираем загрузку только верхней части, но в большинстве случаев мы загружаем ряд заголовков + некоторые KVP, чтобы отобразить некоторую полезную информацию.

Например, в обзорном списке мы показываем идентификатор головы + некоторые значения в столбцах для каждой строки.

ОБНОВЛЕНИЕ: Мы храним любые формы. Итак, в основном мы храним «документы». Тем не менее, мы должны подготовить и выполнить поиск по этим формам по любому значению, сортировке и т. Д. Контроль доступа к данным добавляет еще один уровень сложности в базу данных.

Как вы можете догадаться, количество и доступность определенных KVP варьируется от объекта к объекту. Не существует действительной возможности для создания отдельных таблиц для каждого типа объектов, поскольку нам пришлось бы создавать тысячи таблиц для различных комбинаций данных.

Будет ли этот тип «словаря», как наборы данных, лучше храниться в базе данных noSQL? И получим ли мы от этого преимущества в производительности? Будет ли Кассандра моделировать эти головы + KVP как один набор данных? Глядя на веб-страницу cassandra и некоторые учебные пособия, у меня сложилось впечатление, что между нашими RDBMS и cassandra не так много различий с точки зрения организации данных - у нас остается такое же огромное количество объединений, если вы хотите выбрать 5 KVP. для списка для каждой строки.

Просвещение приветствуется, также есть ссылки на документы, объясняющие проблемы, в порядке.

Есть пара понятий, которые необходимо различать. Один о структуре, а другой о схеме.

Структурированные данные - это данные, в которых приложение заранее знает значение каждого байта, которое оно получает. Хорошим примером являются измерения от датчика. Напротив, поток Twitter неструктурирован. Схема - это информация о том, какая часть структуры передается в СУБД, и как она запрашивается для обеспечения этого. Он контролирует, насколько СУБД анализирует данные, которые она хранит. СУБД, необходимая для схемы, например, SQL Server, может хранить неразобранные данные (varbinary) или необязательные данные (xml) и полностью проанализированные данные (столбцы).

СУБД NoSQL лежат на спектре от разборов (хранилищ значений ключей) и выше. Кассандра предлагает относительно богатую функциональность в этом отношении. Там, где они заметно отличаются от реляционных хранилищ, заключается в однородности данных. После определения таблицы в ней могут храниться только те данные, которые соответствуют этому определению. В Кассандре, однако, даже если столбцы и семейства определены, не требуется, чтобы любые две строки в одной и той же таблице выглядели как-либо по-другому. Разработчик приложения сам решает, сколько всего входит в одну строку (также называемую документом) и что содержится отдельно, с помощью указателей. По сути, сколько денормализации вы хотите.

Преимущество заключается в том, что вы можете получить полный набор данных за одно последовательное чтение. Это быстро. Одним из недостатков является то, что вы, разработчик приложений, теперь несете единоличную ответственность за все проблемы целостности данных и обратной совместимости, навсегда, за каждый бит кода, который когда-либо касается этого хранилища данных. Это может быть трудно понять правильно. Кроме того, вы заблокированы в одной точке зрения на данные. Если вы вводите свои строки по номеру заказа, как вы сообщаете о продажах по какому-либо конкретному продукту, региону или клиенту?

Несмотря на основной поток баз данных noSQL, IMHO решение о внедрении такой технологии должно приниматься в соответствии с достижениями, необходимыми в соответствии с хранимой информацией, а не только с учетом производительности, которой вы в настоящее время обладаете. Это означает, что, возможно, ваш лучший вариант - придерживаться базы данных SQL и улучшать ваше HW.

Но кроме того, я прочитал кое-что в вашем вопросе, что заставило меня задуматься. Текущее состояние вашей базы данных не так много, но ваше предложение «мы в основном храним данные, введенные пользователями различными способами в виде списков« ключ-значение »», заставляет задуматься о том, не является ли проблема плохой моделью данных, а не недостаток физических ресурсов. Я управлял действительно большими таблицами (+10 миллиардов строк) с невероятной производительностью в «традиционных» базах данных SQL.

Я не говорю, что это неправильно, просто потому что, конечно, я не могу оценить вас в правильной модели данных с таким небольшим количеством информации о вашем текущем решении, но просто думаю о пересмотре вашей модели данных в качестве дополнительного варианта наряду с остальными, так как вы может найти какой-то ключ, почесывая там.

Обычно списки ключ-значение хороши в качестве компромисса, когда вы не можете реализовать модель в ее окончательном состоянии, потому что вы не знаете различных ключей, с которыми вам придется столкнуться, или когда вам понадобятся значения одного из возможных ключи для определенного элемента. Но при реализации я обычно хотел бы переосмыслить такие решения через некоторое время, когда вы собрали достаточно информации, чтобы определить общий случай использования и решить, является ли решение модели данных лучшим. Если вы знаете, что у вас будет определенное количество ключей, попробуйте сделать несколько тестов с дизайном обычной таблицы традиционным способом.

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... и добавляя соответствующие индексы. Попробуйте и оцените планы выполнения с обоими подходами. Вы можете быть особенно удивлены, если собираете более одного ключа за раз, поскольку, помимо прочих преимуществ, размер блока данных должен быть уменьшен и, следовательно, производительность будет улучшена.

Надеюсь, что это помогает, или, по крайней мере, расширяет возможности и открывает новую линию для расследования.