×
-
Not Only SQL: ищем альтернативы реляционным базам
-
Not Only SQL: ищем альтернативы реляционным базам
Почему сразу не может? Сделать синхронизацию между инстансами хоть через Атланту — это чисто техническая задач и вполне решаемая, пусть и с небольшими задержками.
Я могу ошибаться, но вполне возможно, что split brain между регионами (что довольно частая ситуация, по крайней мере на моей практике, AWS запада США теряет свой же регион во Франкфурте на пару минут почти каждую неделю) отчасти тоже влияет на выбор данного подхода. Лаг в несколько минут в современном бизнесе не допустим.Например, мне как юзеру, например, все равно сколько транзакция займет времени — полсекунды или 15 секунд или даже минуту
Лично я с вами не могу согласится, если что-то долго работает, то скорее всего я сменю сервис. Как минимум, как показывают продукты, над которыми лично я работаю, скорость ответа является суть ли не найважнейщим параметром в современном мире. -
Not Only SQL: ищем альтернативы реляционным базам
Я практически уверен, что сейчас большинство глобальных сервисов сейчас себе это позволяют. И продажи билетов и букинги гостинниц и тп. Их системы это несколько датацентров в разных регионах мира и ни о каких распределенных транзакциях и речи быть не может.
К сожалению, я снова не смогу привести пруфлинк, но за последние пару лет, я встречал описание подобных ситуаций даже в банковской сфере.
Лично я не считаю это сколько нибудь опрометчивым выбором, опять же, это бизнес решение, пусть, возможно, и продиктованное техническими ограничениями. На мой взляд, действительно немного задач требуют 100% persistence.PS вы осправиваете само существование eventual consistency как подхода? Или утверждаете, что продажи не та область применения?
-
Not Only SQL: ищем альтернативы реляционным базам
Статья была скорее технического плана, но раз такой гигант себе это позволял, значит репутационные/финансовые потери были значительно ниже невозможности самого брониварония.
-
Not Only SQL: ищем альтернативы реляционным базам
Те же ACID транзакции не последовательны, изучите понятия «изоляция транзакций». Самая интересная реализация (на мой взгляд) в ORCL, где за счет версионирования данных можно снижать уровень изоляции, не нарушая целостность данных при параллельной работе.
Сами таблицы не имеют вообще никакого отношения в b-tree, хоть эта структура и встречается довольно часто в РСУБД. Данные таблицы лежат с страницах от 4кб и более (обычно привязано к размеру страницы самой дисковой подсистемы), где каждая строка это последовательность колонок, где одна страница имеет ссылку на другую страницу и тп. Пример на задуматься: почему запрос, содержащий OFFSET 153_000_000_000 работает медленно, а запрос WHERE ID > 153_000_000_000 при налиции индекса быстро?
Не нужно путать SQL язык и сами СУБД. Иначе получается, что тот же RedShift или Vertica это обычные реляционные хранилища.
P.S. На моей последней работе вообще нет SQL,
Скорее говорит о том, что у вас нет ни BI аналитики, ни связных данных с разным жизненным циклом.Рекомендую к прочтению хотя-бы Тома Кайта: Oracle для профессионалов, так как там объясняется как именно работает сама СУБД, а не просто описание SQL языка для чайников. Да, книга специфична для Oracle, но довольно много вещей в базах разных вендоров реализованы схожим образом.
Підтримав: andriy dmytrenko -
Not Only SQL: ищем альтернативы реляционным базам
К сожалению не могу найти ссылку на статью, но лет 8 назад именно так и было на booking.com (или hotels.com, но точно на одном из крупнейших).
Только связано это было с распределенным кластером, в котором нет транзакций, и
отказоустойчивостью каждого региона, что было куда важнее таких конфилктов в днных.
Когда такие конфилкты возникали, они решались именно вручную, предлагая постояльцу номер более высого класса либо другую гостинницу.Підтримав: Anton Martynenko
Простите, но я не понимаю к какому конкретно месту моего комментария ваш ответ относится.
обратите внимание на слово «index», которое не имеет никакого отношения к хранению самих данных в БД. И да, добльшинство РСУБД имеют файловую систему в виде «кучи», хотя такое наименование и встречается довольно редко. Таблицы без индексов это тоже норма, используются в ежедневном обиходе. не пишите, пожалуйста, такие вещи. SQL это язык, ваш любимый SPARK тоже имеет свою реализацию SQL. Тот же Couchbase имеет свой SQL подобный N1QL. Пожалуйста, пользуйстесь правильной терминологией. Второе: само утверждение крайне не корректно, пусть и правдиво для некоторых задач. Ваш же текст утверждает о всеоблемящей более высокой производительности Mongo на MySQL, что не верно (первый же линк из поисковой выдачи stackoverflow.com/…sql-vs-mongodb-1000-reads). Из моей практики жечь балк аплоадом на ec2.medium инстансе можно со скоростью по 100к записей в секунду даже не прибегая к тюнингу самого сервиса MySQL. «BI» аналитики, не пропускайте слова, пожалуйста. Вы только больше убедили меня в корректности моих выводов, спасибо.