текстовое поле sql против плоского файла против хранилища документов nosql - PullRequest
4 голосов
/ 05 декабря 2011

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

Альтернативой, которая, похоже, набирает популярность, является полностью основанное на документах решение NoSQL (например, CouchDB, MongoDB и т. Д.) Мне интересно, каковы компромиссы (масштабируемость / надежность / безопасность / производительность / простота реализации / простота реализации обслуживание / стоимость) между простым использованием текстового поля SQL, указателем на плоские файлы или полным переосмыслением всей системы в контексте хранилища документов NoSQL?

1 Ответ

9 голосов
/ 30 декабря 2013

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

Во-первых, давайте обсудим, почему это плохая идея сохранения больших данных в реляционной базе данных: '

  • размеры строк становятся намного длиннее, поэтому ввод / вывод требуется для чтения на страницах диска с всплывающими подсказками целевых строк
  • размеры резервных копий и, что более важно, резервное копирование раз увеличиваются до такой степени, что они могут нанести вред задачам DBA и даже перевести системы в автономный режим (затем резервные копии отключаются, затем происходит сбой диска, упс)
  • обычно вам не нужно искать текст, поэтому нет необходимости иметь его в базе данных
  • реляционные базы данных и библиотеки / драйверы, как правило, плохо справляются с необычно большими данными, и способ обработки этих данных часто зависит от поставщика, что делает любое решение непереносимым

Ваш выбор "где-то еще" широк, но включает в себя:

  • программное обеспечение для хранения больших данных, такое как Cassandra, MongoDB и т. Д.
  • Базы данных NoSQL, такие как Lucene
  • Файловая система

Делайте то, что легче всего сработает - все они действительны, пока вы выполняете расчеты ваших требований для:

  • пиковая производительность записи
  • пиковая производительность чтения
  • объем длительного хранения

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

...