Если применять горизонтальное шардирование и база данных будет "размазана" по нескольким серверам (например шарды одной большой таблицы будут разнесены на 2 и более физических сервера) то как базу бэкапить и самое главное - как восстанавливать (к примеру, удалена таблица)? В каких СУБД (MySQL, Postgres) это вообще возможно? Поделитесь, пожалуйста, у кого есть опыт.
Saboteur т.е лучше разбивать таблицу на кусочки в пределах одного физ сервера, а если она действительно выросла уж очень сильно(так что шарды одной этой таблицы занимают ресурсы сервера), то лучше (правильно) оставлять ее одну на выделенном сервере а остальные таблицы начинать разносить по другим серверам?
vittmann, Я не очень понимаю, что такое "шарды таблицы занимают ресурсы сервера".
У вас не хватает места на диске? Купите еще один диск.
Таблица очень большая, а на самом деле вся не нужна? Придумайте как она должна делиться. По годам, по логическим разделам.
Не очень понятно, где у вас возникает проблема из-за большой таблицы.
Насчёт подхода с вынесесеним "горячих" данных и архивных это больше с точки зрения написания самого приложения, а я больше интересуюсь с точки зрения администрирования (построения, обслуживания)
Попробую сформулировать.
Используются, к примеру, dedicated сервера у хоcтера. И модифицировать их можно только на этапе покупки. Т.е докинуть диск потом уже не выйдет(такова у них философия нужен сервер с другими характеристиками, пожалуйста, заказывайте новый). После покупки оптимизуруем СУБД так, что бы, например, вся база умещалась в память, тюним, радуемся. Но время идет, база растет (и да, деление крупных таблиц на мелкие части, наверно, будет эффективно до какого-то момента) а потом наступает момент, когда лучше (правильно) оставлять ее (выросшую таблицу, пускай и разбитую на кусочки) одну на выделенном сервере, а остальные таблицы начинать разносить по другим серверам? Или такой подход не используют?
Если так делают, тогда у меня вопрос как раз о эффективном резервном копировании/восстановлении парочки-другой таблиц, одной базы, лежащих на разных физ серверах.Какие инструменты, подход в таком случае?
например шарды одной большой таблицы будут разнесены на 2 и более физических сервера
А это зачем?
Так не делают. Горизонтально делают для увеличения скорости отдачи.
Можно конечно данные разнести на разные сервера, но это делается на уровне архитектуры бизнес-логики, а не на уровне одной таблицы.
Ну, справедливости ради, в Эластике размазывание данных по нодам - стандартный способ шардинга. В случае постгреса/etc, конечно, на ум скорее приходят тейблспейсы и партиционирование.
ky0, Эластик это не скл база, и вы не размазываете одну таблицу по разным нодам. Размазываете индексы целиком, дублируете их, но нет такого, что кусок одного и того же индекса на одной ноде, а кусок на другой
Vitaly Karasik, шарды одной таблицы в смысле куски одной таблицы, или полные копии этой таблицы с репликацией? Вот ведь о чем речь.
sql запрос по разным серверам выполняться не должен
Vitaly Karasik, Суть в том, что штатно в mysql нет такого шардинга. Но есть сторонние решения, и если искать включая платные, там могут быть варианты, как ты описываешь.
Но это нештатное решение. best practice это искать другие решения, без шардинга, пока это возможно.
Vitaly Karasik, ну базу с шардингом бэкапят также, как и без шардинга.
Так как SQL штатно не знает про шардинг, для него это будут просто отдельные таблицы на разных серверах. Каждая бэкапится отдельно. Целостность также поддерживается на уровне этих отдельных таблиц.
Даже без шардинга правильный бэкап большой базы задача нетривиальная.
С шардингом еще труднее. Посмотрите например https://dzone.com/articles/mysql-sharding-devops-c... и другие на тему "sharding backup".
Если у вас нет DBA, советую использовать managed services - AWS RDS и т.п.