Комментарии 5
Ох. Пришлось два раза перечитывать, и во второй раз делал это очень внимательно.)
1) Насчет решения поставленных проблем: в Riak есть link-walking. Как я понял, он нужен как раз для быстрого извлечения связанных данных, типа постов и комментариев. Вы это не пробовали?
2) К описанным класса неплохо бы пример их использования. С чанками я пока так и не понял, надо ли при чтении всей ленты обходить каждый чанк или нет. Потому что, если надо, то алгоритм получается O(N).
3)В начале и далее:
«client a: def o-value = DHT.get(»some-key");
client a: def a-value = changeValue(o-value)..."
на каком-то функциональном языке написано? Просто ниже идет формальное описание и еще обычный java код. По-моему, не стоит все мешать.
1) Насчет решения поставленных проблем: в Riak есть link-walking. Как я понял, он нужен как раз для быстрого извлечения связанных данных, типа постов и комментариев. Вы это не пробовали?
2) К описанным класса неплохо бы пример их использования. С чанками я пока так и не понял, надо ли при чтении всей ленты обходить каждый чанк или нет. Потому что, если надо, то алгоритм получается O(N).
3)В начале и далее:
«client a: def o-value = DHT.get(»some-key");
client a: def a-value = changeValue(o-value)..."
на каком-то функциональном языке написано? Просто ниже идет формальное описание и еще обычный java код. По-моему, не стоит все мешать.
Спасибо, действительно, не очень понятно получилось.
Я внимательно на link-walking не смотрел, но интуитивно кажется, что при их использовании вместе с значением храняться ссылки на другие значения, поэтому операция достать пост вместе с комментариями будет выполняться не за один запрос, а за N, где N — число комментариев, понятно что все это будет происходить внутри кластера и по идеи быстрее, чем снаружи, но все равно, это не один запрос.
При всей чтении всей ленты да, нужно обходить все чанки, но обычно нужна только голова ленты, поэтому достаем последний чанк, смотрим на кол-во элементов там, если мало, то берем еще и предыдуший чанк и возвращаем элементы, а в гуи будет кнопка или автоскрол, который будет подгружать данные из следующего чанка. Получается, что мы можем получить около 100-200 элементов за два запроса при длинне чанка в 100 элементов.
Нет, это просто псевдокод, который иллюстрирует проблему. Я не хотел использовать везде java, потому что получалась портянка кода и нужно было определять контекст, без него не удалось бы скомпилить, а давать куски кода, которые не работают, но выглядят работающими мне не кажется правильным.
Я внимательно на link-walking не смотрел, но интуитивно кажется, что при их использовании вместе с значением храняться ссылки на другие значения, поэтому операция достать пост вместе с комментариями будет выполняться не за один запрос, а за N, где N — число комментариев, понятно что все это будет происходить внутри кластера и по идеи быстрее, чем снаружи, но все равно, это не один запрос.
При всей чтении всей ленты да, нужно обходить все чанки, но обычно нужна только голова ленты, поэтому достаем последний чанк, смотрим на кол-во элементов там, если мало, то берем еще и предыдуший чанк и возвращаем элементы, а в гуи будет кнопка или автоскрол, который будет подгружать данные из следующего чанка. Получается, что мы можем получить около 100-200 элементов за два запроса при длинне чанка в 100 элементов.
Нет, это просто псевдокод, который иллюстрирует проблему. Я не хотел использовать везде java, потому что получалась портянка кода и нужно было определять контекст, без него не удалось бы скомпилить, а давать куски кода, которые не работают, но выглядят работающими мне не кажется правильным.
Про пример с мержем. Правильно ли я понимаю, что если заполнение каментами будет интенсивное (конкурентное и через разные ноды на кластере), то мержить придется чуть ли не при каждом запросе и все равно пользователи рискую видеть разную картину (как бог лоадбаллансер на душу положит)?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Паттерны использования Riak