Вы немного не понимаете, о чем он говорит; он говорит о вращающихся дисках и расходах на чтение с них. Это не проблема Riak.
У них огромное количество данных, которые не могут поместиться в памяти. Он слишком велик даже для того, чтобы легко использовать твердотельные накопители, потому что они не могут втиснуть достаточное количество их в сервер с их текущими ограничениями по размеру (вот почему они перешли от от твердотельных накопителей к вращающимся дискам, как он утверждает в его речь).
Если вы не используете базу данных в памяти (которой не является Riak, если вы не используете серверную часть в памяти), как Мэтт утверждает в этом разделе своего выступления, вы просто ограничены количеством операций ввода-вывода в секунду. диск может дать вам, если вам нужно читать с диска. Нет никакого способа обойти это; вы читаете с диска. Далее он заявляет, что вы хотите кэшировать все, что можете, чтобы помочь с этим.
Примерно так это работает, независимо от платформы базы данных, которую вы используете, когда дело доходит до обращения к дискам; бесплатного обеда нет :)
Если вы используете Riak и ваш набор данных превышает объем доступной памяти, вам придется читать с диска при «промахе кеша». Riak полагается на дисковый кеш базовой ОС, если вы используете серверную часть Bitcask по умолчанию — другие серверные части могут делать это или не делать, а вместо этого выполняют собственное кэширование в памяти.
Что касается вашего вопроса относительно данных об узлах... Riak не имеет мастера и изначально основан на документе Amazon Dynamo. Мы используем последовательное хеширование для распределения данных по кольцу с репликами, которые затем записываются на соседние узлы, контролируемые «значением N», которое вы настраиваете (и это настраивается для каждого сегмента и даже для каждого запроса). Когда вы читаете, этот же метод хеширования используется для определения того, на каком узле «живут» данные.
Чтение будет считываться из (n_val/2) + 1 узлов по умолчанию, но вы можете настроить это для каждого запроса в соответствии с вашими потребностями. При окончательной согласованности нет гарантии, что данные на этих узлах будут одинаковыми в момент времени, когда вы выполняете чтение, и вам может потребоваться выполнить разрешение конфликтов в зависимости от вашей бизнес-логики. При этом следует понимать, что количество времени, в течение которого что-то несовместимо, измеряется в миллисекундах при нормальных операциях (например, у вас нет сетевого раздела или узла, восстанавливающегося после сбоя).
У нас есть тонна информации об этих вещах, доступной на нашем веб-сайте, и мы очень стараемся систематизировать ее, чтобы ее было легко найти. В частности, вы можете посмотреть на Riak — кластеризация, чтобы узнать, как распределяются данные.
person
Brian Roach
schedule
21.07.2012