У Cocaine master, как правило, находится в состоянии персистентной ядерной войны, поэтому лучше собирайтесь из бранча v0.11 — там текущая стабильная версия, которую можно использовать в продакшене.
Про установку я буду рассказывать в следующей статье :)
В планах рассказать про базовую настройку, примеры использования с помощью С++/Python API. Так же надеюсь рассказать про использование HTTP API, но здесь зависит от получившегося объема.
По поводу Cocaine, попробуйте эту документацию, она должна быть сейчас более актуальной, чем на сайте. Статья-туториал для хабра по этому нашему продукту тоже в планах.
Компании, которые работали и работают с Elliptics: Rambler, 2GIS, Ситисофт, Денивип, Undev, Яндекс, Express42 (насколько мне известно, даже Mail.Ru пробует использовать). Некоторые только пробуют, некоторые внедряют, у некоторых в продакшене
Не могли бы уточнить суть вопроса? Сейчас в eblob'е нет никакого ручного склеивания IO запросов, они склеиваются файловой подсистемой linux'а.
Или вопрос про append записи через cache?
В таком случае файловая подсистема не может работать эффективно, так как внутри самого блоба будет происходить много переаллокаций данных. Поясню: для каждого ключа при первой записи выделяется какой-то участок блоба с конца файла. Каждый раз при превышении этого объема выделяется новый участок в блобе, в 2 раза больше текущего, и данные копируются туда, что, очевидно, затратно. Если же мы будет append'ы вначале копить в памяти, то солидной части таких переаллокаций удается избежать, что уже ведет к выигрышу в скорости работы.
Как уже ответили в комментарии к прошлой статье, reverbrain.com — это мы и есть. Данный сайт был создан как площадка для обмена знаниями с пользователями платформы.
Да, причем дефрагментация запускается автоматически, когда объем, занятый удаленными файлами, становится больше задаваемого порога относительно размера блоба.
В накладных расходах. При создании нескольких потоков у нас будет слишком много context switch'ев, + на каждый поток системой выделяется порядка 4 мегабайт на стек.
В итоге асинхронная реализация в 1 потоке имеет все шансы (и на практике так и происходит) работать быстрее, чем тупая реализация, в которой каждый поток посылает запрос, затем ждет ответа.
Со звонками там очень клево сделали — если тянуть сверху вниз, то звонок принимается, а если сверху вниз — то отклоняется. У отклонения, правда, есть разные градации — просто сбросить, выключить звук или отправить ответное смс.
В Яндексе, как и любой другой крупной IT компании, есть несколько уровней собеседований. На первом этапе, как правило, отсеиваются все, кто не знает алгоритмы и самого языка.
А далее, на очных, уже отсеиваются люди с недостаточными знаниями конкретных платформ и по другим более узким критериям.
Насколько мне известно — для решения этой проблемы Яндекс готовить технологию Атом, которая позволит отсортировать выдачу на вашем сайта не раскрывая при этом личных данных пользователя.
В планах рассказать про базовую настройку, примеры использования с помощью С++/Python API. Так же надеюсь рассказать про использование HTTP API, но здесь зависит от получившегося объема.
По поводу Cocaine, попробуйте эту документацию, она должна быть сейчас более актуальной, чем на сайте. Статья-туториал для хабра по этому нашему продукту тоже в планах.
А что вы имеет в виду под «системой хранения файлов»?
Или вопрос про append записи через cache?
В таком случае файловая подсистема не может работать эффективно, так как внутри самого блоба будет происходить много переаллокаций данных. Поясню: для каждого ключа при первой записи выделяется какой-то участок блоба с конца файла. Каждый раз при превышении этого объема выделяется новый участок в блобе, в 2 раза больше текущего, и данные копируются туда, что, очевидно, затратно. Если же мы будет append'ы вначале копить в памяти, то солидной части таких переаллокаций удается избежать, что уже ведет к выигрышу в скорости работы.
Вообще, названия придумывали разные люди, но, согласитесь, — они клевые :)
P.S. А с Eblob'ом все просто — это Elliptics BLOB (который, в свою очередь, Binary Large OBject)
В итоге асинхронная реализация в 1 потоке имеет все шансы (и на практике так и происходит) работать быстрее, чем тупая реализация, в которой каждый поток посылает запрос, затем ждет ответа.
Сложность следующей строчки O(n) и выполняется она O(m) раз, где m — длина оригинальной строки, т.к. количество уникальных слов, в общем случае, O(m).
Решение же с кучей работает за O(m log m + n log n), что всегда быстрее.
А далее, на очных, уже отсеиваются люди с недостаточными знаниями конкретных платформ и по другим более узким критериям.