Comments 20
Если речь о клиенте — то NoSQL скорее всего не нужен и тот же MySQL — разумный выбор. На сервере все не так просто — из-за надежности (Partition Tolerance, буква 'P' в CAP теореме) многим приходится жертвовать. Меня, например, удивило
> это 20 миллионов отдельных наборов, по одному на пользователя — т.е. если сервер с моим блокнотом умрет, я буду ждать восстановления из бэкапа (в лучшем случае)?
> это 20 миллионов отдельных наборов, по одному на пользователя — т.е. если сервер с моим блокнотом умрет, я буду ждать восстановления из бэкапа (в лучшем случае)?
Там может быть NFS + VPS, то есть, облака, по модному. И восстановится довольно быстро — время загрузки OS и серверного ПО.
Может быть и репликация, тогда вообще без простоя.
А, скорее всего, и то и то.
Может быть и репликация, тогда вообще без простоя.
А, скорее всего, и то и то.
Речь идет о сервере. Каждый шард (логический сервер, на котором живут несколько сотен тысяч пользователей) представлен физически двумя машинами, между которыми осуществляется репликация, и делается периодический бэкап. Так что в лучшем случае, если один из серверов шарда умрет, то пользователи этого не заметят. В худшем — если умрет сразу два сервера (что сильно маловероятно), данные шарда будут восстановлены из бэкапа дневной давности. Пока у нас ни того ни другого не происходило. Бывали временные сбои на индивидуальных серверах шардов, которые можно было отследить и оперативно поправить.
>База данных не даст нам удалить блокнот, в котором еще есть заметки, благодаря ограничению >FOREIGN KEY.
плакал крокодильими слезами которые они прожигали линолеум.
плакал крокодильими слезами которые они прожигали линолеум.
CouchDB — ACID и при этом NoSQL. И с масштабированием все в порядке.
База — блокнот. Документ — запись. Все вписывается. Правда вьюхи разрастаются быстро.
Ошибся веткой или что? Я про ACID говорил, однако.
Нет. Просто от одного ACID мало толку если модель не ложится в базу без костылей (join tables например).
1. Надобность джоинов зачастую переоценена
2. В NoSQL джоины, как правило, не нужны вообще.
Я использую CouchDB в своих проектах уже почти 3 года и до сих пор не перестаюсь удивляться, зачем я вообще раньше реляционные базы юзал. Не встречал у себя еще ни одной ситуации, где реляционность давала бы хоть какое-то преимущество. Всё то, что писал раньше на SQL, сейчас гораздо легче и лучше получается на CouchDB.
2. В NoSQL джоины, как правило, не нужны вообще.
Я использую CouchDB в своих проектах уже почти 3 года и до сих пор не перестаюсь удивляться, зачем я вообще раньше реляционные базы юзал. Не встречал у себя еще ни одной ситуации, где реляционность давала бы хоть какое-то преимущество. Всё то, что писал раньше на SQL, сейчас гораздо легче и лучше получается на CouchDB.
> 2. В NoSQL джоины, как правило, не нужны вообще.
Так в том и прелесть большинства NoSQL решений.
> Я использую CouchDB в своих проектах уже почти 3 года и до сих пор не перестаюсь удивляться, зачем я вообще раньше реляционные базы юзал. Не встречал у себя еще ни одной ситуации, где реляционность давала бы хоть какое-то преимущество. Всё то, что писал раньше на SQL, сейчас гораздо легче и лучше получается на CouchDB.
Бухгалтерия. Все, больше SQL нигде вроде бы не нужен. CouchDB сам использую, не могу представить свою жизнь без map/reduce. Правка у кауча есть некоторые моменты которые вынуждают использовать другое решение.
Так в том и прелесть большинства NoSQL решений.
> Я использую CouchDB в своих проектах уже почти 3 года и до сих пор не перестаюсь удивляться, зачем я вообще раньше реляционные базы юзал. Не встречал у себя еще ни одной ситуации, где реляционность давала бы хоть какое-то преимущество. Всё то, что писал раньше на SQL, сейчас гораздо легче и лучше получается на CouchDB.
Бухгалтерия. Все, больше SQL нигде вроде бы не нужен. CouchDB сам использую, не могу представить свою жизнь без map/reduce. Правка у кауча есть некоторые моменты которые вынуждают использовать другое решение.
Насколько я знаю, аббревиатура пишется как NOSQL и читается как Not Only SQL. Это не отрицание SQL, а попытка его расширить.
И все указанные фичи есть во многих NOSQL реализациях.
Я считаю, пока, основной минус NOSQL — это то, что такие движки все еще остаются экзотикой: относительно мало информации, проектов на которых откатались бы многие подводные камни и баги, специалистов, к тому же нет единых стандартов и соответственно альтернатив.
И все указанные фичи есть во многих NOSQL реализациях.
Я считаю, пока, основной минус NOSQL — это то, что такие движки все еще остаются экзотикой: относительно мало информации, проектов на которых откатались бы многие подводные камни и баги, специалистов, к тому же нет единых стандартов и соответственно альтернатив.
Если вызов API проходит успешно, то 100% изменений будут выполнены, а если вызов API не удается, то не будет сделано ни одно из них. Это значит, что если у нас не получается поместить четвертое изображение в вашу заметку, то в вашем аккаунте не останется наполовину сформированная заметка, которая, к тому же, будет высчитана из оставшегося ежемесячного объема для загрузки данных.
Непротиворечивость. В конце любого вызова API аккаунт находится в полностью рабочем и внутренне непротиворечивом состоянии. У каждой заметки есть свой блокнот, и ни одна из них не находится в подвешенном состоянии. База данных не даст нам удалить блокнот, в котором еще есть заметки, благодаря ограничению FOREIGN KEY.
Гарантированность. Когда сервер сообщает, что блокнот был создан, клиент может считать, что блокнот у него уже есть и учитывать это в дальнейших операциях (таких как вызов на создание заметки). Это изменение гарантированно, и клиент знает, что оно консистентно отражает состояние сервиса в любое время.
А подчкажите, какое из этих требований нарушает та же Cassandra?
Чтобы соревноваться с реляционной БД Cassandra не лучший кандидат — она делалась немного для другого. Если же буквально отвечать на вопрос, то Cassandra не поддерживает транзакций и с разными значениями Consistency Level == ONE клиент может иногда получать устаревшие данные. Но это осознанный выбор разработчика.
Действительно, тот случай, когда данные прекрасно отображаются на реляционную модель. Проверенные временем SQL решения тут будут работать отлично, обеспечивая приемлимый уровень производительности и надежности. Важно не городить огород из самых модных систем, а использовать то, что лучше подходит для конкретного случая.
Каждый из этих высокоуровневых запросов к API осуществляется посредством единственной SQL-транзакции, которая гарантирует, что клиент может полностью доверять любому ответу сервера.
А как вы обеспечиваете одну транзакцию БД на два вызова Thrift-сервисов?
А как вы обеспечиваете одну транзакцию БД на два вызова Thrift-сервисов?
Sign up to leave a comment.
ПочемуSQL?