Комментарии 21
С Phoenix пока не доводилось работать. Но как я и писал, из той же Impala вполне себе можно тоже писать SQL-запросы к HBase
>HBase is an open-source non-relational distributed database modeled after Google's Bigtable and written in Java.
Почему в русском взяли и перевели non-relational как noSQL — мне лично невдомек. Согласитесь, что модель базы и язык для доступа к ней — это все-таки разные вещи. Особенно с учетом наличия финикса (потому что SQL-то как раз есть). Вот одна из первых реляционных баз от IBM была с языком QBE — и что, она от этого стала не реляционной разве?
Ну то есть, не то чтобы это было принципиально, а просто почему не называть как у авторов?
Надо перечитать первоисточник.
Например?
И какой тогда смысл вообще у термина noSQL, если даже отсутствие SQL для этой БД он не означает? Вот что такое не реляционная — я могу понять, это например графовая (и это название осмысленное). Или документо-ориентированная. Или key-value например. Это все термины, которые что-то говорят.
Признаться, как человек, который никогда в глаза не видел NoSql, но много слышал, а до сих пор живёт в мире SQL выглядит интересно, ещё бы сравнение с обычным SQL.
С «академической» же точки зрения… Полагаю, что организовать релевантный эксперимент будет очень непросто из-за сильных различий как в алгоритмах, так и в используемом инструментарии
"эффективный поиск, не приводящий к full table scan, возможен исключительно по ключу" — это не в случае с hbase, а в любом случае. Особенно в случае rdb
Любая мутация по "друзьям" будет минимум 2О(n), так как необходимо у каждой пары провести изменения.
И это без учета операций на перестройку индексов и т.д.
" так как теперь нам не надо вычитывать всю строку и перебирать ее колонки" — а проверки на уже существующего друга?
В итоге получаем не революцию или эволюцию, а реанимацию какого нибудь foxpro или упаси Господь Lotus Notes. Все попытки перейти на ordb как то не очень увенчались успехом.
Вся прелесть HBase скорее в этом. Немного… на ручном управлении, но работает. В смысле, понастраивать придется, особенно если в данных есть какие-то перекосы, то распределять их по регионам равномерно — то еще занятие.
Любая мутация по "друзьям" будет минимум 2О(n), так как необходимо у каждой пары провести изменения.
Если мы храним "обратный" список, то да.
..." так как теперь нам не надо вычитывать всю строку и перебирать ее колонки" — а проверки на уже существующего друга?
Это утверждение для "Изменение данных: добавление друга". Для проверки уже существующих друзей перебор остается, о чем указано абзацем выше в "Чтение данных"
mongodb 1 документ per user
{userId: 1, friends: [3,5,8,4,2,1]}
поиск по id документа моментальный, перебор массива еще более моментальный даже если он размером 32 мб.
У friends же доступ к элементу поди O(n), и если мы хотим найти там X, то нам бы хотелось снизить этот порядок например до логарифма (и хранить хешмап). И да, в HBase зачастую грузят в качестве значения просто сериализованный Avro, например, где внутри есть и массивы, и много чего еще.
С учетом вычислительной мощности конкретного ноутбука экспериментально был выбран запуск для n = 10, 30, …. 170
оценивать алгоритмическую сложность на БД с неполными двумя сотнями записей? вы это серьёзно?
В целом замечание резонное.
При n = 10, 30, …. 200 общее время теста доходило уже до 30-35 минут, что для меня было уже чересчур (учитывая, что финальные тесты я запускал ни раз, и еще бесчисленное число раз при отладке). Мне важно было подтверждение или опровержение характера изменения времени. Уже n = 10, 30, …. 170 оказалось для этого достаточно как оказалось.
Уже n = 10, 30, …. 170 оказалось для этого достаточно как оказалось.
нет.
ваши выводы несколько гхм… наивные.
O(1) в реальной жизни не бывает (если не брать совсем уж тривиальные операции вроде «прочитать первую запись»), после какого-то объёма данных производительность падает.
если мы говорим про хэш-таблицы, то растёт число коллизий и/или приходится увеличивать размер хэша, таблицы перестают помещаться в кэше процессора, а потом и в оперативной памяти, etc.
Особенности проектирования модели данных для NoSQL