• Redis vs SQLite vs PostgreSQL

    CKOPOBAPKuH
    @CKOPOBAPKuH
    Молоток vs Кувалда vs Отвёртка

    Я решил выяснить, какой из инструментов лучше. Представил одинаковую задачу — ударять себя по большому пальцу ноги. Отвёртку решил держать за ручку и ударять наконечником, так как неудобно держать за наконечник и ударять ручкой. Для молотка и кувалды это одинаковые схемы. Запросы: ударить по большому пальцу и измерить время, сколько болит.

    Результат: если ударить больно, то палец болит. В чём же тогда прелесть отвёртки? Понимаю, что она подходит для узконаправленных задач, например, только откручивание или закручивание, т.е. для ограниченных задач. В остальном одни минусы: и держать неудобно, и площадь поражения невелика, и по пальцу я попал только с третьего раза.

    PS: Что вы используете для надёжного перманентного отбивания пальцев? Холивар классический русский молоток vs молоток из икеи можно опустить, разницы между ними практически не будет.
    Ответ написан
    4 комментария
  • Redis vs SQLite vs PostgreSQL

    @Ghostwriter
    1. В Redis лучше представлена работа с коллекциями. Простой пример — инкрементальный счётчик. Вы делаете incrby/hincrby для любого ключа, не заботясь о его наличие в хранилище. В Postgres аналогичная функциональность на основе последовательностей (nextval('foo')) подразумевает, что вы уже создали последовательность 'foo' ранее. Это подталкивает вас на написание процедур, которые перед попыткой изменить счётчик, сначала проверяют его наличие, при необходимости создают его и только потом изменяют. Больше ручной работы.

    2. Структуры данных в Redis оптимизированы либо под быстрый поик О(1), либо под компактность и приемлемую произволительность O(N), O(log(N)). Практически всегда получается обходиться простыми или вложенными хеш-таблицами с О(1) или О(n). В Postgres вы практически всегда пользуетесь той или иной разновидностью B/R-tree, GiST/GIN индексов со сложностью O(log(N)(+N)). До версии 8.4, индексы типа HASH в Postgres имели практически схожую с B-tree скорость поиска, поэтому их применение не имело никакого смысла. Сейчас, в версии 9.1, смысла стало больше, но не намного — HASH индексы не поддерживают Write-Ahead Log и при сбоях требуют ручной переиндексации:
    "Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash. They are also not replicated over streaming or file-based replication. For these reasons, hash index use is presently discouraged." http://www.postgresql.org/docs/9.1/static/indexes-types.html

    У себя в проектах, я использую и Redis, и Postgres. Первый — как эффективную систему для сбора онлайн-статистики (счетчики-лайки, различные метрики), а второй — как хранилище для пользовательских аккаунтов и контента с его мета-информацией. При этом, наметилась тенденция переносить контент на HBase, оставляя для Postgres только задачи по ACID-обслуживанию операций с пользовательскими аккаунтами.
    Ответ написан
    Комментировать