До недавнего времени я использовал mongo, чтобы попытаться сдержать волну массовых обновлений MySQL на системных серверах, однако, прочитав это:
http://www.mikealrogers.com/2010/07/mongodb-performance-durability/
Я остановил производство монго-версии своего сайта до тех пор, пока монго не станет более стабильным.
Некоторые предложили мне использовать _change в couche DB для создания нового объекта mongo, который решит основные проблемы в mongo db atm, но я не уверен в этом.
Я изучал другие БД, такие как redis и Cassandra, но с тех пор я отказался от Cassandra, поскольку вам нужно разрабатывать для своих запросов, и это слишком ограничивает мой сайт (плохая модуляция). На самом деле я не ищу объединения и т. Д., Я просто ищу возможность поиска в строке, а не только по идентификатору семейства столбцов, поскольку это может затруднить программирование при попытке добавить новые функции. Это было бы здорово для поисковой системы или чего-то еще, но не очень хорошо для настоящего веб-сайта, такого как facebook, в целом (а не только в поиске по почте).
Мне было интересно, какой опыт имели люди здесь, пытаясь найти работоспособное решение проблем со скоростью SQL. Есть ли серебряная пуля для всего этого или это просто случай, когда вам нужно сжать зубы с MySQL или другим SQL db, если вам нужна надежность?
Возможно, это нечто среднее между формой кеширования и SQL (я заметил, что facebook использует тяжелое кеширование на своих настенных страницах и т.д., возможно, почему).
Спасибо,
В чем конкретно ваша проблема с Mongo? В любом случае вам нужно будет делать резервные копии. Теперь он поддерживает наборы реплик, поэтому вы действительно не привязаны к отказу машины.
Если вы сейчас используете 25 серверов, вы можете легко запустить набор реплик из нескольких серверов и не иметь единой точки отказа.
10-30 миллионов строк - это действительно не много. Тем более, что с решением noSQL вы, вероятно, сможете объединить несколько строк в отдельные записи. Если у вас 2 миллиона пользователей, возможно, большая часть их данных уместится в отдельные записи. (Лимит 4 мб - это много)
Вы действительно не представляли себе масштаб вашего сайта, который имеет огромное значение для того, какая технология / метод подходит.
В любом случае ничто не может быть волшебной пулей. Большинство вещей, о которых вы говорите, касаются возможности большого масштабирования, а не отказа от масштабирования вообще.
Даже использование чего-то вроде memcached перед базой данных требует немного другого мышления, чтобы получить от него все преимущества. Одно из первых действий, которое вам нужно сделать (а если вы еще этого не сделали, можно значительно сэкономить), это проанализировать и оптимизировать запросы, которые вы делаете.