Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, gandjustas, Вы писали:
G>>И это еще "детский" уровень. Потому что у взрослых РСУБД есть в свои системы аналитики, рядом с которыми Druid выглядит как поделка. GIV>Подавятся "взрослые" СУБД объемами хадупа.
О каких объёмах речь?
10 миллиардов строк — 40 ТБ данных на ms sql. На ОДНОМ сервере, работает нормально. Там правда охренеть какой сторедж.
Здравствуйте, gandjustas, Вы писали
GIV>>Подавятся "взрослые" СУБД объемами хадупа. G>О каких объёмах речь? G>10 миллиардов строк — 40 ТБ данных на ms sql. На ОДНОМ сервере, работает нормально. Там правда охренеть какой сторедж.
В таком режиме он будет работать на несколько сотен запросов в секунду. Ну и объём тоже по нынешним меркам средненький, серьёзные приложения на порядки больше данных используют.
Здравствуйте, WolfHound, Вы писали:
S>>>О нем уже не говорят. Ну да, свою нишу заняло, но воплей уже нет. C>>Ну так он победил РСУБД и стал обычным инструментом. WH>А NoSQL уже научился ACID? Или всё так же данные теряет?
Кстати, насчёт ACID.
Здравствуйте, gandjustas, Вы писали:
g> О каких объёмах речь? g> 10 миллиардов строк — 40 ТБ данных на ms sql. На ОДНОМ сервере, работает нормально. Там правда охренеть какой сторедж.
Объемы HBase/Hadoop/&Co начинаются от десятков-сотен ТБ (до первого ПБ это такой игрушечный кластер на десяток-другой серверов).
Здравствуйте, Sharov, Вы писали:
S>Типа того, оператор like сущ. с незапамятных времен. json тоже будет такой строкой. Там какой-то минимум операций с json возможен, но про типизацию я не уверен. Т.е. тупо строка.
Можно делать индексацию по части JSON, Постгрес это умеет.
Здравствуйте, gandjustas, Вы писали:
G>В MS SQL Server есть clustered columnstore indexes. Друид и прочие "column oriented written in java" неврно курят в сторонке. G>И это еще "детский" уровень. Потому что у взрослых РСУБД есть в свои системы аналитики, рядом с которыми Druid выглядит как поделка.
С интересом выслушаю ваше мнение — зачем в Яндексе применяют Apache Cassandra.
Война из серии "пила лучше чем топор". У каждого инструмента есть свои преимущества и свои недостатки. И грамотный специалист будет использовать именно подходящий инструмент там где он нужен, а не рассказывать о том, что рубанок нафиг не нужен, раз у меня надфиль есть.
Здравствуйте, smeeld, Вы писали:
C>>Ну так он победил РСУБД и стал обычным инструментом. S>C фига ли? OLTP весь был и остаётся на RDBMS.
Уже нет. Amazon — небольшая компания, которая продаёт в год товаров на сумму ВВП небольшой страны. RDBMS запрещены везде, где нужно OLTP. На использование RDBMS нужно получать разрешение на уровне VP.
Гугл — примерно аналогично. RDBMS не используются нигде, где есть что-либо критичное к скорости.
S>А это ключевая отрасль (финансы, логистика, ВПК...). Ниша NoSQL-веб помойки типи мордокниги и яши.
RDBMS живёт разве что в классических финансах, где самое сложное — это зачислить и снять деньги со счёта (которых максимум десятки миллионов).
Здравствуйте, Cyberax, Вы писали:
C>Никаких распределённых транзакций, естественно, нет. Они просто нереальны при таких нагрузках.
Если их нет, то как идёт обработка ситуации что одного из нескольких товаров не оказалось на складе?
Часть шардов уже уменьшила счётчики, а один сказал, что товар закончился. Что делать?
Как откатить транзакцию?
И это я ещё о сбоях говорить не начинал.
Как такое сделать на шардах каждый из которых умеет внутри себя ACID я знаю.
Как жить без ACID не ясно совершенно.
C>С шардингом, репликацией, танцами с бубном, облаком супер-пупер-DBA и инженеров из Oracle. Смогли победить, лишь разрешив запись с небольшого числа узлов и переведя все остальные в read-only.
Звучит как одна база, запущенная на нескольких машинах.
А шарды это когда базу разрезают на несколько кусков.
C>ВНЕЗАПНО оказалось, что overhead от синхронизационного трафика, нужного для обеспечения ACID, растёт почти экспоненциально с числом пишущих узлов.
Тут алгоритм распределённого консенсуса виноват.
К счастью уже изобретён алгоритм, работающий почти без накладных расходов.
hashgraph называется. Если его запускать в локальной сети и без криптографии, то он решит все проблемы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Anton Batenev, Вы писали:
AB>Они не теряли данные и без ACID
Если нет ACID, то потеря данных вопрос времени.
AB>(ну если руки хотя бы чуть выше поясницы), но для особо страждущих некоторые умеют (правда не очень понятно зачем).
Вот как раз монга и теряла. Брала и разваливалась.
А вот SQL серверы просто работают.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
WH>>Ну максимум что туда можно положить это лайки, посты и фотки котиков. C>Угу. И ещё сотни миллионов покупок на миллиарды долларов.
То есть цена потери транзакции десяток долларов.
При такой цене можно терять десятки транзакций каждый день и всем будет плевать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
WH>>А NoSQL уже научился ACID? Или всё так же данные теряет? C>Кстати, насчёт ACID.
C>А РСУБД разве её уже научились делать?
Да вроде всегда умели. А что есть сомнения?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>А NoSQL уже научился ACID? Или всё так же данные теряет? C>>Кстати, насчёт ACID. C>>А РСУБД разве её уже научились делать? WH>Да вроде всегда умели. А что есть сомнения?
Так они тоже не умеют. Распределённые транзакции X/Open не гарантируют целостности.
Здравствуйте, WolfHound, Вы писали:
C>>Никаких распределённых транзакций, естественно, нет. Они просто нереальны при таких нагрузках. WH>Если их нет, то как идёт обработка ситуации что одного из нескольких товаров не оказалось на складе?
Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
WH>Часть шардов уже уменьшила счётчики, а один сказал, что товар закончился. Что делать? WH>Как откатить транзакцию?
Транзакций нет, о них можно забыть. Есть только некоторые атомарные операции, которые работают на уровне одной записи.
WH>Как такое сделать на шардах каждый из которых умеет внутри себя ACID я знаю. WH>Как жить без ACID не ясно совершенно.
А нету ACID в РСУБД, это просто фантазии DBA, которые не видели ничего дальше БД на одной машине.
C>>С шардингом, репликацией, танцами с бубном, облаком супер-пупер-DBA и инженеров из Oracle. Смогли победить, лишь разрешив запись с небольшого числа узлов и переведя все остальные в read-only. WH>Звучит как одна база, запущенная на нескольких машинах. WH>А шарды это когда базу разрезают на несколько кусков.
Так именно так и делают. Базу режут на части, и дополнительно части хранят в нескольких экземплярах.
C>>ВНЕЗАПНО оказалось, что overhead от синхронизационного трафика, нужного для обеспечения ACID, растёт почти экспоненциально с числом пишущих узлов. WH>Тут алгоритм распределённого консенсуса виноват.
Нет. Виновата необходимость сериализации транзакций.
C>Уже нет. Amazon — небольшая компания, которая продаёт в год товаров на сумму ВВП небольшой страны. RDBMS запрещены везде, где нужно OLTP. На использование RDBMS нужно получать разрешение на уровне VP.
Amazon-компания, способная разрабатывать свой софт, это или не под силу большинству отраслевых финструктур, или не хотят они этого(делать что ли больше нечего). К тому же, Amazon волен использовать любое своё поделие, отраслевые финструктуры-только сертифицированное, а там только решения на базе RDMS, и изменений в ближайшее время не предвидится (какие изменения когда они с Cobol всё никак слезть не могут!).
Что касается способности Amazon сваять OLTP без RDBMS, то это вообще без проблем. Это софт, в нём можно реализовать многими способами любые фантазии и ситуации (как в Матрице: "что хочешь-то и получишь"). Другое дело, что разработка, деплоймент, поддержка всего этого самописного может тупо не уложиться в бизнес схемы и процессы большинства отраслевых финструктур, им проще, а главное, надёжней и даже дешевле будет тупо купить оракел и не париться. Речь не о том, что нельзя OLTP на NoSQL, речь о том, что такое счастье далеко не всем нужно, почти всем оно не нужно.
We used to use RDBMS just about everywhere but NoSQL solutions scale better and are more reliable at high operational loads so they are our most common choice for high value operational systems. We are very big users of DynamoDB. Relational systems have more functionality and support richer query so they remain a great choice for data warehousing and analytic workloads and we use them extensively. We use vast numbers of Redshift clusters and AuroraDB. Generally, we’ve learned that using the same database everywhere is a bad idea and we aim to use the right database system for the workload.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, WolfHound, Вы писали:
C>>>Никаких распределённых транзакций, естественно, нет. Они просто нереальны при таких нагрузках. WH>>Если их нет, то как идёт обработка ситуации что одного из нескольких товаров не оказалось на складе? C>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Что ты имеешь ввиду под "нормально кешировать данные" и какая РСУБД этого не умеет? V>Они практически все умеют, кто умеют автоматическую репликацию, но итоговое быстродействие неудовлетворительное.
Что именно умеют?
Я знаю как работают MS SQL, Oracle, Postgres и немного MySQL. Я не понимаю о какой части движка ты говоришь.
Можешь подробнее?
