Ответы пользователя по тегу Масштабируемость
  • Postgres-XL - как добавить новый узел?

    voidnugget
    @voidnugget
    Программист-прагматик
    Там есть проблемы...

    Надо костыли типа Slony или Stolon
    Что бы миграции "расползлись" по кластеру как-то.
    Для миграций можно liquibase c местным formatted SQL'ем.

    Накатывать можно чем-угодно.

    В принципе Postgres-XL уже потерял свою актуальность PG11 + stolon / pg_pathman хватает с головой, ещё можно Citus, но имхо он слишком толстый. Если надо map/reduce'ить - лучше план вручную написать.
    Ответ написан
  • Простейший решардинг для PostgreSQL?

    voidnugget
    @voidnugget
    Программист-прагматик
    Зависит от конкретной версии PostgreSQL'я.
    Если самый простейший - можно с коробки в 9.5 через postgres_fdw вот так . В <9.5 нельзя так как там внешние таблички (foreign tables) не могут наследоваться. Cам fdw afaik однопоточный по историческим причинам, по этому имеет смысл хранить сразу несколько шардов в пределе одного сервера.

    Если нужна поддержка, и что-то попроще чем ванильный SQL, то лучше взять какое-то готовое расширение (extension) типа pg_shard, и потом докупить у них же их плюшки к PostgreSQL'ю по потребности. pg_shard умеет только операции равности (equality) хешей столбцов у шардов, эт значит что если выползти за границы таблички любым range query - оно начнёт бороздить все шарды, что порядком надоедает. Реализацию операций сравнения (больше/меньше) хешей пока не замечал, хотя давно его не ковырял. Т.е. хоть это и довольно таки простое решение, без понимания его ограничений чуть более чем наверняка можно напороться на квазилион граблей. Иногда складывается впечатление что разработчики специально затягивают feature list для того что бы клиенты переходили на их платный CitusDB.

    Уууу.... CitusDB сегодня заопенсорсили.

    PostgreSQL-XC нынче чуток морально устарел, и на его основе был разработан PostgreSQL-XL, про который уже упоминалось на хабре. Поддержки как таковой у него нет, но есть пару российских вендоров которые в нём перманентно ковыряются, так как это сугубо опенсорсятинка. Имхо, по функционалу оно на много превосходит pg_shard, и с ним нет таких дурацких проблем, хоть и разворачивается в разы сложнее, не без полуночного красноглазия.
    Ответ написан
    2 комментария
  • Какую СУБД лучше выбрать?

    voidnugget
    @voidnugget
    Программист-прагматик
    Эмм... для начала нужно выучить мат часть и разобраться что такое B-tree и R-tree и как они фигурируют в современных СУБД, разобраться что такое "6ая нормальная форма" (второй курс универа).

    Если это мускуль у которого "бесконечная длинна" таблички - от 200Гб и до 1Тб, то достаточно просто использовать ENGINE ARCHIVE c R-tree индексом. В противном случае (если меньше 200Гб) нужно (учить мат часть и вправлять мозги) рефакторить базу. Лучше слезть с MySQL на PostgreSQL, а вот c MongoDB - куча проблем. Стандартные СУБД на основе B-tree для баз от 200Гб+ не подходят. MySQL исключение из-за модульности системы хранения, имеется ввиду ENGINE ARCHIVE, но так как там нет T-tree - нужен нормальный кэш. PostgreSQL даже похуже будет - нужно ковырять различные расширения типа cstore_fdw и т.п.

    uint64 ID'шник в виде хэша - очень спорное решение, даже если и предположить что в какой-то вселенной нет коллизий, то точно не в этой, и дополнительно нужно прогонять фильтр Блума. Хотя, лучше всего, просто использовать композитные ключи и не заморачиваться.

    Можно ещё попробовать HBase в Apache Phoenix обернуть, там уже есть всё готовое - и фильтр Блума и индексация, можно даже X-tree оформить. HBase, кстати, хорошо масштабируется на запись, а Cassandra, наоборот, - на чтение.

    Шардинг (партицирование) и репликацию нужно оформлять когда схема хорошо нормализирована, и когда более-менее ясно какие таблички нужно масштабировать на запись, а какие на чтение - где-то нужен CA, где-то CP, а где-то AP... (CAP теорема)

    Очень весело в PostgeSQL писать сишные функции для агрегации в материализованные представления, особенно весело с GPGPU.
    Ответ написан