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


9

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответы:


3

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

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

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

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


1
В нашем случае данные, которые мы храним, в основном представляют собой данные. Пользователь определяет форму во время выполнения и может изменять ее в любое время. Форма может быть построена из тысяч полей. Это может произойти, если захвачены данные в виде списка. Если бы мы знали данные заранее - во время разработки базы данных, мы бы нормализовали их. Ваш комментарий о представлении данных заставляет меня задуматься: если формы написаны в виде документа, как вы создаете представление для них для списка или сортируете данные по полю в реальной жизни? Map-уменьшить данные, вспомнить и подготовить список в коде?
THST

Исторически все это было на стороне клиента - вы вернули свои документы и сделали то, что должны были. В CQL есть пункты, с которыми знаком любой разработчик SQL. Map Reduce - доступная архитектура для больших наборов данных. И похоже, что у Cassandra 3.0 будут материализованные представления .
Майкл Грин

5

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

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

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

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

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

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

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


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

Понял. Я не знаю, насколько это сложно, но как идея попробовать, сработает ли создание таблицы, содержащей пул общих ключей, на которые ссылается заполненная пользователем таблица с помощью исполняющего FK, может быть INTEGER? Может быть, это немного лучше, чем индексирование столбца varchar, который, если он меняется очень динамично, думаю, он не будет коротким. И это также уменьшит размер индекса.
LironCareto

1
Это уходит от вопроса, но мы обсудили некоторые ограничения возможностей пользователя. Например, уменьшите поля max app-table до 10 vanilla varchar db-fields. Это денормализация схемы для выбора в основном набора данных заголовка и 10 значений столбца приложения за один раз или с максимальным одним объединением в дополнительной таблице базы данных. При изменении соответствующих значений нам также потребуется изменить эту одну строку базы данных в коде. Это представляется возможным и уменьшает количество объединений до 10 для выбора для отображения таблицы приложения. Тем не менее, изменение определения пользовательского столбца приложения очень дорого.
THST

1
Это нормально, не волнуйся. Я думаю, что понимаю вашу точку зрения, и ваш подход выглядит для меня как хороший компромисс между улучшением производительности и осуществимостью. Важно иметь статистику использования, чтобы определить эти поля. Вы оценили это? По крайней мере, это может выиграть вам время, пока вы не найдете (лучше? Окончательное?) Решение или, возможно, обнаружите, что вы можете работать с этим в течение длительного времени.
LironCareto
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.