Потому что это так для поиграться сделано, на слова разбивается просто по пробелам. Знаки препинания как часть слова в этом случае воспринимаются или как отдельное слово.
Не считаю это оптимизацией, тем более преждевременной. Всегда пишу ++smth, если не нужно предыдущее значение и smth++, если нужно. В циклах for оно, как правило, ни к чему, поэтому ++smth. Просто, хороший тон, имхо.
Где-то видел ещё замеры скорости компиляции для разных случаев, если уж совсем с ума сходить :)
В самом плохом случае вам дают просто key-value хранилище, в котором можно хранить всё что угодно. Данные режутся на небольшие блоки и по ключу автоматом раскидываются по серверам. Дальше крутитесь как хотите :)
В зависимости от реализации могут быть всякие плюшки, вроде раздельного хранения атрибутов в value или хранения в каждом атрибуте списка атрибутов. Могут быть даже индексы, но это совсем не правило. В той же Кассандре, которую фейсбук использует, индексы появились совсем недавно, а в Гипертейбл их просто нет.
Но за все плюшки надо платить, скажем обычно индекс должен жить только на одном сервере, репликация есть, но нет распределённых индексов. В Монго вообще забава, индекс должен влезать в оперативку, не влезает — всё извините, живите без индекса. Хотите возможность перебирать данные по ключу в порядке возрастания значения ключа, теряете в распределении нагрузки по серверам. Хотите хранить большое кол-во атрибутов по каждому ключу, готовьтесь к построению субиндексов по их именам, благо это делается автоматом при большом кол-ве атрибутов, но они начинают жрать память даже когда не нужны, т.к. становятся частью значения.
Скорость появляется в тех задачах, где достаточно исользования key-value хранилища, как key-value хранилища. Плюс к этому, полная согласованность данных не гарантируется, а иногда вовсе понижается до того, что только один сервер в кластере может иметь актуальные данные. Поэтому, запись в базу может выглядеть просто как сохранение в оперативку с отложенной на неизвестный срок репликацией — соответсвенно, скорость при «записи» очень большая.
Если сравнивать с РСУБД, где всё предсказуемо, то пока nosql это зыбучие пески, но это моё мнение. Особняком стоит Редис — сервер структур данных, имхо, в нём есть некоторые просчёты, но сама идея выносить реализацию и хранение структур данных очень притягательная. Короче много всего у nosql, и плюсов и минусов, долго и лень писать, сотрясая воздух :)
Там просто нет индексов, доступ возможен только по «первичному ключу». Если нужны выборки по значениям данных, то либо руками строить индексы, либо использовать встроенные возможности, которые не везде есть. В результате, скорость аналогичная РСУБД и геморрой. В этом, извините, заключается жопа nosql решений.
К сожалению задачка NP-сложная, рисовать будет годами, да и формализовать постановку сложно. Данные многомерные, измерений по количеству вершин, и не факт что есть какая-то красивая «проекция» на плоскость. Поэтому чаще задачу переформулируют как «нарисовать прикольный граф», и тут уже начинаются эвристики и прочее :)
Если совсем с ума сходить, можно посчитать теоретический минимум необходимой энергии для сохранения и изменения состояния одного бита информации. Но можно проще, посчитать относительный КПД, скажем P4 выдавал порядка 10k MIPS, а тот же i7 выдаёт порядка 50k MIPS при сравнимом тепловом пакете — КПД в 5 раз больше.
Почитал, на сколько я понял, фильтр Блума там используется для быстрой проверки на отсутствие слова в словаре исключений. А сами словари в виде trie представлены.
Честно говоря, долго пытался придумать пример наглядно показывающий, почему при одном массиве и нескольких функциях эффективность выше, чем при одном массиве и одной функции. Ни одной интуитивно понятной аналогии мне так в голову и не пришло, поэтому решил об этом не писать.
Фишка в том, что при заданной вероятности ложного срабатывания, одной функии и конечном кол-ве элементов, которые предполагается запомнить фильтром, эффективность фильтра ниже, поскольку все те «избыточные» биты, которые были введены для удерживания кол-ва ошибок выше определённого потолка, «никак» не используются.
Если ввести вторую функцию, то эти «неиспользуемые» биты разделяются между ними, при этом кол-во необходимых бит на ключ растёт линейно, а точность экспоненциально.
obama
putin
dobby
мир
труд
Где-то видел ещё замеры скорости компиляции для разных случаев, если уж совсем с ума сходить :)
В зависимости от реализации могут быть всякие плюшки, вроде раздельного хранения атрибутов в value или хранения в каждом атрибуте списка атрибутов. Могут быть даже индексы, но это совсем не правило. В той же Кассандре, которую фейсбук использует, индексы появились совсем недавно, а в Гипертейбл их просто нет.
Но за все плюшки надо платить, скажем обычно индекс должен жить только на одном сервере, репликация есть, но нет распределённых индексов. В Монго вообще забава, индекс должен влезать в оперативку, не влезает — всё извините, живите без индекса. Хотите возможность перебирать данные по ключу в порядке возрастания значения ключа, теряете в распределении нагрузки по серверам. Хотите хранить большое кол-во атрибутов по каждому ключу, готовьтесь к построению субиндексов по их именам, благо это делается автоматом при большом кол-ве атрибутов, но они начинают жрать память даже когда не нужны, т.к. становятся частью значения.
Скорость появляется в тех задачах, где достаточно исользования key-value хранилища, как key-value хранилища. Плюс к этому, полная согласованность данных не гарантируется, а иногда вовсе понижается до того, что только один сервер в кластере может иметь актуальные данные. Поэтому, запись в базу может выглядеть просто как сохранение в оперативку с отложенной на неизвестный срок репликацией — соответсвенно, скорость при «записи» очень большая.
Если сравнивать с РСУБД, где всё предсказуемо, то пока nosql это зыбучие пески, но это моё мнение. Особняком стоит Редис — сервер структур данных, имхо, в нём есть некоторые просчёты, но сама идея выносить реализацию и хранение структур данных очень притягательная. Короче много всего у nosql, и плюсов и минусов, долго и лень писать, сотрясая воздух :)
Фишка в том, что при заданной вероятности ложного срабатывания, одной функии и конечном кол-ве элементов, которые предполагается запомнить фильтром, эффективность фильтра ниже, поскольку все те «избыточные» биты, которые были введены для удерживания кол-ва ошибок выше определённого потолка, «никак» не используются.
Если ввести вторую функцию, то эти «неиспользуемые» биты разделяются между ними, при этом кол-во необходимых бит на ключ растёт линейно, а точность экспоненциально.