Какие проблемы масштабируемости Вы встретились с использованием хранилища данных NoSQL? [закрытый]

Фактически, мой текущий проект.

Хранение 18 000 объектов в нормализованной структуре: 90 000 строк в 8 различных таблицах. Потребовалась 1 минута, чтобы получить и сопоставить их с нашей объектной моделью Java, при этом все правильно проиндексировано и т. Д.

Сохранение их в виде пар ключ / значение с использованием облегченного текстового представления: 1 таблица, 18 000 строк, 3 секунды, чтобы получить их все и реконструировать объекты Java.

С точки зрения бизнеса: первый вариант не представлялся возможным. Второй вариант означает, что наше приложение работает.

Сведения о технологии: работает на MySQL как для SQL, так и для NoSQL! Придерживаясь MySQL для хорошей поддержки транзакций, производительности и проверенной репутации, чтобы не повредить данные, достаточно хорошо масштабировать, поддерживать кластеризацию и т. Д.

Наша модель данных в MySQL теперь состоит только из ключевых полей (целых чисел) и большого «значения» поле: просто большое ТЕКСТОВОЕ поле.

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

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

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

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

На сайте Тодда Хоффа highscalability.com есть много интересного о NoSQL, включая некоторые тематические исследования.

Коммерческая колоночная СУБД Vertica может подойти для ваших целей (даже несмотря на поддержку SQL): она очень быстра по сравнению с традиционными реляционными СУБД для аналитических запросов. См. недавний доклад Стоунбрейкера и др. на CACM, в котором Vertica противопоставляется map-reduce.

Обновление: И Twitter выбрал Cassandra вместо нескольких других, включая HBase, Voldemort, MongoDB, MemcacheDB, Redis и HyperTable.

Обновление 2: Рик Кэттелл только что опубликовал сравнение нескольких систем NoSQL в Высокопроизводительных хранилищах данных. А на сайте highscalability.com статья Рика опубликована здесь.

Я использовал redis для хранения сообщений журнала на разных машинах. Это было очень легко реализовать и очень полезно. Redis действительно крут

Не хочу. Я хотел бы использовать простое и бесплатное хранилище ключевых значений, которое я мог бы вызывать в процессе, но такой вещи не существует afaik на платформе Windows. Сейчас я использую Sqlite, но я хотел бы использовать что-то вроде Tokyo Cabinet. У BerkeleyDB есть лицензионные "проблемы".

Однако если вы хотите использовать ОС Windows, ваш выбор баз данных NoSQL ограничен. И не всегда есть поставщик C#

Я попробовал MongoDB, и она оказалась в 40 раз быстрее Sqlite, так что, возможно, мне стоит использовать ее. Но я все еще надеюсь на простое технологическое решение.

У меня нет непосредственного опыта, но я нашел эту запись в блоге довольно интересной.

Мы заменили базу данных postgres на базу данных документов CouchDB, потому что отсутствие фиксированной схемы было для нас большим преимуществом. . Каждый документ имеет переменное количество индексов, используемых для доступа к этому документу.

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

CouchDB: конкретный пример

По сути, приложение textme использовало CouchDB для решения проблемы растущих данных. Они обнаружили, что SQL был слишком медленным для работы с большими объемами архивных данных, и перешли на CouchDB. Это отличное чтение, и он обсуждает весь процесс выяснения того, какие проблемы может решить CouchDB и как они в итоге их решили.

Мы перенесли часть наших данных с mysql на mongodb, не столько для масштабируемости, сколько потому, что она лучше подходит для файлов и нетабличных данных.

В настоящее время мы храним:

• 25 тысяч файлов (60 ГБ)
• 130 миллионов других "документов" (350 ГБ)

с ежедневным оборотом около 10 ГБ.

База данных развернута в "парной" конфигурации на двух узлах (6x450GB sas raid10) с apache/wsgi/python клиентами, использующими mongodb python api (pymongo). Дисковая установка, вероятно, избыточна, но это то, что мы используем для mysql.

Не считая некоторых проблем с потоковыми пулами pymongo и блокирующей природой сервера mongodb, это был хороший опыт.

Мы переместили некоторые данные, которые мы использовали для хранения в Postgresql и Memcached, в Redis . Хранилища значений ключей намного лучше подходят для хранения данных иерархических объектов. Вы можете хранить данные больших двоичных объектов намного быстрее и с гораздо меньшими затратами времени и усилий на разработку, чем использование ORM для сопоставления большого двоичного объекта с РСУБД.

У меня есть клиент c # redis с открытым исходным кодом , который позволяет сохранять и извлекать любые объекты POCO с одной строкой:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

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

Я считаю Redis «управляемым текстовым файлом» на стероидах, который обеспечивает быстрый, одновременный и атомарный доступ для нескольких клиентов, поэтому все, что я использовал для использования текстового файла или встроенной базы данных, теперь использую Redis. например Чтобы получить в режиме реального времени объединенный журнал ошибок для всех наших служб (что, как известно, было для нас сложной задачей), теперь можно выполнить всего за пару строк, просто предварительно отложив ошибку в списке на стороне сервера Redis, а затем обрезка списка, чтобы сохранить только последние 1000, например:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);