未加星标

Migrating My Data FromParse

字体大小 | |
[数据库(综合) 所属分类 数据库(综合) | 发布者 店小二05 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

As you probably already know, Parse announced it’s ending their hosting services on January 28, 2017. The migration plan was divided in two steps : first, we need to host the databases of our apps, and later on we should deploy our own, open source, Parse Server. During the first stage, the clients (iOS, Android, etc.) will keep hitting Parse’s servers, and they will access the newly migrated data; after the second stage is done and your server is up and running, the clients should be updated to point to the new server. The recommended schedule by the Parse team is to migrate the database by April 28, and finish setting up your self-hosted Parse Server by July 28. Yes, you read it right if you haven’t migrated your database, you have less than a month to do so .

“ But where should I start from? ”, you may ask. As any decision, the pros and cons must to be taken into account, also considering the different conditions: do you have only one or multiple apps on Parse? They store huge amounts of data, or not so much? Do you have experience managing databases, specially MongoDB? How sensitive is your data? What is your budget?

As most of my apps have a small, niche audience, the amounts of data are really small. None of the databases is higher than 10 MB, even with a few thousand users, installation, and other objects. Also, most of them are free, with some humble contributions or donations occasionally. Therefore, I have a small budget to keep them functioning. As I have zero experience managing databases, I can’t build all the MongoDB server by myself (for example, I didn’t even know of some concepts like sharding, replica sets, and more). I started researching all the different options available in the market, to find what would fit my needs.

Ok, so what are my options now?

Suggested by the Parse Team, there are mLab and ObjectRocket , who provide from what I’ve read excellent DB-as-a-service. mLab would be a good fit for me, their prices start from U$15 per GB/database/month (the free tier is not intended for production usage). I have around 6 apps in production, and they require different databases, so the monthly cost would be almost U$100 per month, and we aren’t even talking about hosting the Parse Server yet. (Actually, if you are using only Parse Server, and not migrating from hosted Parse, you can use only one database for different apps, by defining a collectionPrefix ).

Unfortunately, the prices and sizes that ObjectRocket offer aren’t for indie/side projects, so I needed to cross them as well from my list, together with mLab and Compose.io . While reading the community links and googling more, I’ve found Clever Cloud . I almost chose them to host my DBs: you can host as many mongo dbs you want, and it’s free up to 500 MB; but if you need more than that, it jumps from a free 500 MB, to a 75 /month for 30 GB, and I needed something in the middle.

Also, as an option for a replacement of all Parse services, there are also NodeChef , ParseGround , Backand and Back4app . But as now I have the possibility to have control over the whole parse stack, I preferred not to depend too much again on another service. It’s a personal decision; check them out because they may be a good fit for you, if you don’t want to worry at all with the backend.

After a few weeks, when I was about to give up, I found Scalegrid.io , that provided exactly what I needed: a place where I can create many Mongo DBs under the same infrastructure (a cluster). Someone to manage the hard part, but with the control that I want. Similarly, there is also MongoDB Cloud Manager , which is an excellent product from MongoDB Inc. itself. I preferred to go with Scalegrid, but the process I describe in the next section is very similar for both solutions.

Setting up my first MongoDB server

After signing up for a 30 day free trial, I checked which one of the services would fit me better: (1) hosting, where I provide my AWS keys or own hardware, and they manage it, or (2) management, where I don’t need to worry about the hardware that will host the dbs. In my case, I preferred to have control also over the underlying instances, so I chose the first option. Price-wise, they are very similar at the end of the day in the first, you need to pay AWS and Scalegrid.io, while in the second you pay a little more but only for Scalegrid.io. According to my calculations, it would be something very close. So this is what I did, and what you should do to set it up:

Create a new user the AWS account and generate the keys (Acces Key Id and Secret Acces Key). Remember to save this keys, as you won’t get them again from AWS. Created a new “Cloud Profile” in the Scalegrid console using the AWS keys. Created a new cluster using this profile. It means that the AWS EC2 instances will be created, by Scalegrid, in your AWS account. Bear in mind that you will need to choose a few options: Size (micro gives you 10GB of storage); The version of Mongo (Parse only supports officially 2.6 and 3.0 for now); To enable replica sets and sharding if you don’t have high traffic and don’t need redundancy, you probably don’t need; To encrypt and compress the data I suggest to set both to yes; To enable SSL (more on the last paragraph) it’s recommended, but not required. Wait for a few minutes (you can see the instance being created in the AWS console), and your cluster will be ready to go. Now y

本文数据库(综合)相关术语:系统安全软件

主题: MongoDBAndroidiOSInc.
分页:12
转载请注明
本文标题:Migrating My Data FromParse
本站链接:http://www.codesec.net/view/482198.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(39)