NOsql Vs Mysql - Движение без схемы с Кассандрой - PullRequest
1 голос
/ 03 ноября 2010

Вот факты:

  • У нас есть много (LOT) данных, поступающих каждый день.
  • Каждый файл, который мы получаем, находится в формате CSV, и пока естьпара заголовков, которые повторяются чаще, чем другие, на самом деле не является стандартом.
  • Нормализация каждого файла для загрузки в базу данных MySQL отнимает много времени и часто подталкивает нас к изменению схемы (новое полепоявился в файле, который ранее не существовал ..).
  • Хотя первичный ключ является уникальным, все остальное может быть продублировано
  • Это записи клиентов (например, электронная почта, имя, фамилия,город, штат, адрес и т. д.)
  • У нас может быть несколько электронных писем для одного и того же лица.
  • Мы читаем 70% времени и пишем 30% времени
  • Масштабируемость может быть проблемой, но сейчас это не так, хотя ключевым фактором является доступность
  • Скорость - это то, что мы ищем.Mysql слишком медленный, чтобы отвечать на запросы, где в таблицах более 50 миллионов записей.Даже при хорошей оптимизации у нас слишком много проблем со скоростью.Разбивка таблиц стала организационной проблемой.Схема менее noSQL казалась привлекательной.Что бы вы порекомендовали, что вы реализовали?(Пожалуйста, не отвечайте, чтобы оптимизировать MySQL .. бессмысленно и не по теме)

-

1 Ответ

3 голосов
/ 04 ноября 2010

Давайте рассмотрим следующие моменты:

У нас много (LOT) данных, поступающих каждый день.

Все решения NoSQL в основном созданы для масштабирования до большого размера.числа (Riak, MongoDB, Cassandra и т. д.)

... заголовки, которые повторяются чаще, чем другие, на самом деле не является стандартом ... Нормализация каждого файла для загрузки вБаза данных mySQL отнимает много времени и часто подталкивает нас к изменению схемы

NoSQL определенно подходит для этой модели, многие из них «без схемы», поэтому эти дополнительные поля легко хранить.Это, однако, будет стоить вам дополнительного пространства, поскольку имена полей обычно хранятся вместе с документом.

Хотя первичный ключ является уникальным, все остальное может быть продублировано

"Документ-ориентированные "и" Key-Value "базы данных хорошо подходят для этого, если ключ предоставлен.Если вам нужно выполнить повторные проверки, то большинство баз данных ключ-значение плохо оснащены.«Документно-ориентированная» база данных может быть немного лучше оснащена, но не намного.

У нас может быть несколько электронных писем для одного и того же человека

Большинство этих баз данных имеютнекоторое понятие «массивы как базовый тип».CouchDB и MongoDB хранят объекты как JSON, поэтому легко увидеть, как клиент может получить массив электронных писем без необходимости «объединять таблицы».MongoDB также предоставляет функции «атомарного обновления», такие как «$ addToSet», которые хорошо работают с массивами.

Мы читаем 70% времени и пишем 30% времени. Масштабируемость может быть проблемой, но этоне сейчас, хотя доступность является ключевым фактором

Все основные базы данных NoSQL разработаны для масштаба .(читает и пишет)

Единственный способ доступности - через аппаратное и локальное резервирование (ничем не отличается от MySQL или других баз данных).Несмотря на низкий номер версии, многие из этих баз данных используются в производственных средах очень крупными компаниями, поэтому многие простые случаи рассматриваются.Это все еще нетронутая территория, но мы также миновали «случайные сбои, когда ничего не изменилось» фаза.

Скорость - это то, что мы ищем ... Схема меньше noSQLказалось привлекательным.Что бы вы порекомендовали, что вы реализовали?

У нас есть сотни гибких пользовательских записей в MongoDB.Производительность на отдельных поисках действительно потрясающая.

Однако вам следует с осторожностью относиться к типу выполняемых запросов.

Если вам нужно запустить запросы, которые возвращают сразу несколько пользователей, вы 'у нас будут проблемы с быстродействием практически любой из этих баз данных Key-Value или Document-Oriented.Возможно, вы захотите взглянуть на базу данных Graph или другое причудливое решение.Однако, если все ваши варианты использования сосредоточены вокруг одного пользователя за раз, взгляните на MongoDB .

MongoDB также поддерживает встроенное уменьшение карты, так что вы сможете масштабировать "не"-реальное время "запросов.

...