Мы создаем приложение для iOS с Parse.com, но до сих пор не можем найти правильный способ эффективного резервного копирования данных.
В качестве предпосылки у нас есть и будет МНОГО строк хранилища данных. Скажем, у нас есть класс с 1 миллионом строк, предположим, что у нас есть его резервная копия, а затем мы хотим вернуть его в Parse после опасной ситуации (например, потери данных на производстве).
Несколько решений, которые мы рассмотрели, следующие:
1) Использовать внешний сервер для резервного копирования
Резервное копирование: - используйте REST API для постоянного резервного копирования данных на удаленный сервер MySQL (мы выбрали MySQL для целей индивидуальной аналитики, так как для нас гораздо быстрее и проще обрабатывать данные с помощью MySQL)
ImportBack: а) — воссоздать объекты JSON из резервной копии MySQL и использовать REST API для отправки обратно в Parse. Скажем, мы используем пакетную операцию, которая позволяет одновременно создавать 50 объектов с помощью 1 запроса, и предположим, что на каждый запрос требуется 1 секунда, 1 миллион наборов данных будет передан в Parse за 5,5 часов.
б) - воссоздать один файл JSON из резервной копии MySQL и использовать панель инструментов для импорта данных вручную. Мы только что попробовали этот метод с файлом из 700 000 записей: потребовалось около 2 часов, чтобы индикатор загрузки остановился и показал количество строк на левой панели, но теперь он никогда не открывается на правой панели (он говорит «время работы истекло» ) и прошло более 6 часов с момента начала загрузки.
Таким образом, мы не можем полагаться на 1.b, а восстановление 1.a после аварии занимает слишком много времени (если у нас есть 10 миллионов записей, это будет примерно 55 часов = 2,2 дня).
Сейчас мы думаем о следующем:
2) Постоянно копировать данные в другое приложение
Создайте следующее в Parse: - Рабочее приложение: A - Приложение для репликации: B Таким образом, пока A находится в производстве, каждый отдельный запрос будет дублироваться в B (постоянно используя фоновое задание). Недостатком, конечно же, является то, что он съест предел пакета A, поскольку он просто удвоит количество запросов. Так что не идеально думать о масштабировании.
Нам нужно что-то вроде AWS RDS, которое дает возможность ежедневного автоматического резервного копирования. Интересно, как это может быть сложно для Parse, поскольку он основан на инфраструктуре AWS.
Пожалуйста, дайте мне знать, если у вас есть какие-либо идеи по этому поводу, буду рад поделиться ноу-хау.
P.S.:
Мы заметили важный недостаток в приведенной выше 2) идее.
Если мы реплицируем с помощью REST API, все идентификаторы объектов всех классов будут изменены, поэтому все отношения 1to1 или 1toMany будут нарушены.
Поэтому мы думаем о том, чтобы поместить uuid для каждого класса объектов.
Есть ли проблемы с этим методом? Одна вещь, которую мы хотим достичь, это query.include("ObjectName") (или в Obj-C "includeKey"), но я полагаю, что это будет невозможно, если мы не будем основывать логику нашего приложения на objectId.
Ищете обходной путь для этой проблемы; но будет ли управление на основе UUID работать в логике хранилища данных Parse?
