PD
По хранилищу - партиционирование.
По ядрам - RAC
По ядрам - RAC
Хм, а в чем разница между семейством столбцов и строкой в оракле?
Нет ничего общего между NoSQL, это не система, это "определение от противного"
Size: a a a
2020 December 24
N
Если мы говорим про column family, то разница например в том, что в оракле в каждой строке есть значения всех колонок ( но только последнии, которые могут принимать null могут отсутствовать, а в column family это не обязательно вообще. в строке может быть только 1 колонка, а все другие значения не быть совсем.
PD
Nikolay
Если мы говорим про column family, то разница например в том, что в оракле в каждой строке есть значения всех колонок ( но только последнии, которые могут принимать null могут отсутствовать, а в column family это не обязательно вообще. в строке может быть только 1 колонка, а все другие значения не быть совсем.
Чем отличается хранение по строкам - с одной стороны, и все прочие NoSQL - с другой?
Принципиально?
Принципиально?
N
По хранилищу - партиционирование.
По ядрам - RAC
По ядрам - RAC
это не так. партиционивание - это не шардирование.
PD
А в чем разница для решаемой задачи? Разделение данных - есть. Разделение ядер - есть. Масштабирование - есть.
Зачем что-то еще?
Зачем что-то еще?
PD
Там есть и data grid, но я про совсем старшие лицензии оракла плохо знаю.
PD
Nikolay
Если мы говорим про column family, то разница например в том, что в оракле в каждой строке есть значения всех колонок ( но только последнии, которые могут принимать null могут отсутствовать, а в column family это не обязательно вообще. в строке может быть только 1 колонка, а все другие значения не быть совсем.
На самом деле в Pg тоже может быть из кучи формальных столбцов реально хранится только одна - а остальные в TOAST или в связанных хранилищах типа jsonb
N
Чем отличается хранение по строкам - с одной стороны, и все прочие NoSQL - с другой?
Принципиально?
Принципиально?
не совсем понятен вопрос. вот в column family довольно сильные отличия. в оракле у нас занчения всех колонок(за исключением крайних нулл), а тут в строке можно держать значения только некоторых. у нас могут различаться набор колонок во времени!
N
А в чем разница для решаемой задачи? Разделение данных - есть. Разделение ядер - есть. Масштабирование - есть.
Зачем что-то еще?
Зачем что-то еще?
разница в том, что сторадж при шардировании другой, а при партиционировании общий. разные iops
PD
Nikolay
не совсем понятен вопрос. вот в column family довольно сильные отличия. в оракле у нас занчения всех колонок(за исключением крайних нулл), а тут в строке можно держать значения только некоторых. у нас могут различаться набор колонок во времени!
Как это "всех"? А blob?
Но в книге не про разницу между column family и row tables, а про принципиальную разницу между хранением по строкам (с одной стороны) и всеми прочими вариантами с другой. Я вот этого не вижу.
Но в книге не про разницу между column family и row tables, а про принципиальную разницу между хранением по строкам (с одной стороны) и всеми прочими вариантами с другой. Я вот этого не вижу.
PD
Nikolay
разница в том, что сторадж при шардировании другой, а при партиционировании общий. разные iops
Э, при партиционировании можно разные партиции на разные tablespace убрать, вот и разные стораджи.
PD
Собственно, ради этого обычно партиционирование и делают.
PD
Разница (в теории) в том, что партиционирование - только про сторадж, а шардирование - про (сторадж+ядра+память).
Но внутри оракла просто для этого используются разные решения - и все.
Но внутри оракла просто для этого используются разные решения - и все.
PD
Но если продукт умеет в партиционирование и что-то типа RAC, то шардирование ему уже не нужно.
Шардирование было решением задачи "хотим масштабироваться" для "бедных", так как в бесплатных СУБД не было решений для партиционирования и, тем более, RAC.
Шардирование было решением задачи "хотим масштабироваться" для "бедных", так как в бесплатных СУБД не было решений для партиционирования и, тем более, RAC.
PD
И в современных noSQL ты скорее увидишь именно подход Оракла, нежели шардинг в классическом виде (исключение, разве что, VoltDB)
PD
Ну и репликацию, конечно )
E
Э, в какой предметной области шардинг по географии имеет смысл?
Ну, вот у Dell в штатах вырастет нагрузка еще на порядок - и что? Страна-то одна
Ну, вот у Dell в штатах вырастет нагрузка еще на порядок - и что? Страна-то одна
сервис знакомств badoo :) - как-то слушал в пол уха их рассказ, как у них базы устроены. вот ровно так - шарды по регионам. и, по-моему, они ещё и физически разнесены по этим самым регионам.
PD
Насколько помню, там не шард на регион, а группа шардов на регион и размещена поближе к потребителю.
И это понятно зачем. Но внутри региона несколько шардов (одного у баду не хватило бы...)
И это понятно зачем. Но внутри региона несколько шардов (одного у баду не хватило бы...)
PD
Может у них и региональная специфика так же. Но это не про шардирование, а про собственный CDN )
E
Возможно, что на один регион у них и несколько шардов - это давно было, я уже не помню.
Пример привёл 😊
А переписка выше выглядит как спор ради спора 😊
Пример привёл 😊
А переписка выше выглядит как спор ради спора 😊