I am building an app that allows people to share items with other people in the community. I wanted to use AWS as my platform.
My idea was to use react Native for the app. AWS Cognito for the authentication. AWS lambda for the server calls. Relational database for storing data about the items and user data such as geolocation. Dynamodb for real-time chat, requests for borrowing and transaction data between users. My primary focus is low cost and I was thinking of using PostgresSQL for relational database.
What do you guys think of my database choices. Of course the PostgresSQL database on rds. Is there a flaw in database plan so far? Any help would be greatly appreciated.
I would probably just use DynamoDB for everything in your application. I don't see a real need to storing some of your data in an RDS database here. However if you definitely need a relational database, I would suggest AWS Aurora Serverless so that your entire application would be using serverless AWS services. Also, normal relational database connection pools don't work that well in AWS Lambda, so I would suggest using the new Data API.
Looking to build a react-native app and was going to use MongoDB Atlas for the database, express/apollo/graphql mixed in there for better querying. Has anyone had any experience with these techs together? especialy MongoDB Atlas and express?
I'm not sure how all these techs link together. Any tutorials will be handy as well. Thanks.
MongoDB Atlas provides you the endpoint where you can connect to the replica set and use mongodb.
This takes over many other factors such as installing mongodb, backups and restore. Also, the endpoint(connection string) provided by MongoDB Atlas comes with built-in:
Authentication enabled
Authorized users
Replica set to maintain HA
All of these factors give you advantages of using MongoDB Altas so that you can focus on developing your apps
Using mongodb atlas is likely to give you same things you would expect from your local mongodb and express with additional advantages listed above
If you're planning on using MongoDB and GraphQL in a NodeJs service in the interest of getting better querying capabilities, I'd suggest looking at GraphQL-to-MongoDB, or how I learned to stop worrying and love generated query APIs.
Disclaimer: I wrote that blog post.
MongoDB Atlas just announced GraphQL support for Atlas and Stitch. In a nutshell , you can easily generate/ create Schema for a collection in Atlas, Define access rules, relations and generate queries and mutations. GraphiQL is also integrated to run and test your queries. Check this blog post for more details - https://www.mongodb.com/blog/post/introducing-graphql-support-in-mongodb-atlas-with-stitch
We have an EZ Publish 5 already operational with an Oracle 11g database as a persistence backend.
We planned to get rid of Oracle and we know that we could use Postgresql for sure as a new RDBMS, but we also planned to use MongoDB whenever it's possible.
So the question is: Can we pair EZ Publish 5 to a MongoDB NoSQL database ?
Quick answer: You cannot now as there is no MongoDB driver implemented.
There was a NoSQL Driver planned in the 5.x series, but it is not yet implemented in the latest eZ Publish 2013.06.
With the official roadmap not being updated since the 4.6 release, it hard to guess when the NoSQL driver will be implemented, and if MongoDB will be supported.
Theorically, as the new persistence API make it "easier" to add new storage drivers, you could write a custom MongoDB storage driver.
But in practice implementing a storage driver is quite complex and resource consuming.
Contacting the eZ Systems office in your region and directly ask them when a MongoDB driver will be available might be fastest way to get a clear answer.
I hope it helps.
It is not currently possible as there is no storage engine implemented for MongoDB.
It is indeed planned to implement a NoSQL engine, but there is no version tag on this for now.
However, the new persistence API makes it possible to "easily" implement such a storage engine, but you will be limited by the fact that eZ Publish 5 still uses the legacy back office which runs in the legacy stack (so with 4.x infrastructure which is not compatible with NoSQL).
In short: Implementing a new storage engine will make it only accessible from Public API and REST API.
Since ez5 is a symfony application you can achieve this the symfony way
http://symfony.com/doc/current/bundles/DoctrineMongoDBBundle/index.html
just remember they have renamed the app folder and the appkernel.php.
Haven't tried it yet though
I want to use a NoSQL database on Windows Azure and the data volume will be very large. Whether a Azure Table storage or a MongoDB database running using a Worker role can offer better performance and scalability? Has anyone used MongoDB on Azure using a Worker role? Please share your thoughts on using MongoDB on Azure over the Azure table storage.
Table Storage is a core Windows Azure storage feature, designed to be scalable (100TB 200TB 500TB per account), durable (triple-replicated in the data center, optionally georeplicated to another data center), and schemaless (each row may contain any properties you want). A row is located by partition key + row key, providing very fast lookup. All Table Storage access is via a well-defined REST API usable through any language (with SDKs, built on top of the REST APIs, already in place for .NET, PHP, Java, Python & Ruby).
MongoDB is a document-oriented database. To run it in Azure, you need to install MongoDB onto a web/worker roles or Virtual Machine, point it to a cloud drive (thereby providing a drive letter) or attached disk (for Windows/Linux Virtual Machines), optionally turn on journaling (which I'd recommend), and optionally define an external endpoint for your use (or access it via virtual network). The Cloud Drive / attached disk, by the way, is actually stored in an Azure Blob, giving you the same durability and georeplication as Azure Tables.
When comparing the two, remember that Table Storage is Storage-as-a-Service: you simply access a well-known REST endpoint. With MongoDB, you're responsible for maintaining the database (e.g. whenever MongoDB Inc (formerly 10gen) pushes out a new version of MongoDB, you'll need to update your server accordingly).
Regarding MongoDB Inc's alpha version pointed to by jtoberon: If you take a close look at it, you'll see a few key things:
The setup is for a Standalone mongodb instance, without replica-sets or shards. Regarding replica-sets, you still get several benefits using the Standalone version, due to the way Blob storage works.
To provide high-availability, you can run with multiple instances. In this case, only one instance serves the database, and one is a 'warm-standby' that launches the mongod process as soon as the other instance fails (for maintenance reboot, hardware failure, etc.).
While 10gen's Windows Azure wrapper is still considered 'alpha,' mongod.exe is not. You can launch the mongod exe just like you'd launch any other Windows exe. It's just the management code around the launching, and that's what the alpa implementation is demonstrating.
EDIT 2011-12-8: This is no longer in an alpha state. You can download the latest MongoDB+Windows Azure project here, which provides replica-set support.
For performance, I think you'll need to do some benchmarking. Having said that, consider the following:
When accessing either Table Storage or MongoDB from, say, a Web Role, you're still reaching out to the Windows Azure Storage system.
MongoDB uses lots of memory for its own cache. For this reason, lots of high-scale MongoDB systems are deployed to larger instance sizes. For Table Storage access, you won't have the same memory-size consideration.
EDIT April 7, 2015
If you want to use a document-based database as-a-service, Azure now offers DocumentDB.
I have used both.
Azure Tables : dead simple, fast, really hard to write even simple queries.
Mongo : runs nicely, lots of querying capabilities, requires several instances to be reliable.
In a nutshell,
if your queries are really simple (key->value), you must run a cost comparison (mainly number of transactions against the storage versus cost of hosting Mongo on Azure). I would rather go to table storage for that one.
If you need more elaborate queries and don't want to go to SQL Azure, Mongo is likely your best bet.
I realize that this question is dated. I'd like to add the following info for those who may come upon this question in their searches.
Note that now, MongoDB is offered as a fully managed service on Azure. (officially in Beta as of Apr '15)
See:
http://www.mongodb.com/partners/cloud/microsoft
or
https://azure.microsoft.com/en-us/blog/announcing-new-mongodb-instances-on-microsoft-azure/
See (including pricing):
https://azure.microsoft.com/en-us/marketplace/partners/mongolab/mongolab/
My first choice is AzureTables because SAAS model and low cost and SLA 99.99% http://alexandrebrisebois.wordpress.com/2013/07/09/what-if-20000-windows-azure-storage-transactions-per-second-isnt-enough/
some limits..
http://msdn.microsoft.com/en-us/library/windowsazure/jj553018.aspx
http://www.windowsazure.com/en-us/pricing/calculator/?scenario=data-management
or AzureSQL for small business
DocumentDB
http://azure.microsoft.com/en-us/documentation/services/documentdb/
http://azure.microsoft.com/en-us/documentation/articles/documentdb-limits/
second choice is many cloud providers including Amazon offer S3
or Google tables https://developers.google.com/bigquery/pricing
nTH choice manage the SHOW all by myself have no sleep MongoDB well I will look again the first two SAAS
My choice if I am running "CLOUD" I will go for SAAS model as much as possible "RENT-IT"...
The question is what my app needs is it AzureTables or DocumentDB or AzureSQL
DocumentDB documentation
http://azure.microsoft.com/en-us/documentation/services/documentdb/
How Azure pricing works
http://azure.microsoft.com/en-us/pricing/details/documentdb/
this is fun
http://www.documentdb.com/sql/demo
At Build 2016 it was announced that DocumentDB would support all MongoDB drivers. This solves some of the lack of tooling issues with DocDB and also makes it easier to migrate Mongo apps.
Above answers are all good - but the real answer depends on what your requirements are. You need to understand what size of data you are processing, what types of operations you want to perform on the data and then select the solution that meets your needs.
One thing to remember is Azure Table Storage doesn't support complex data types.It supports every property in entity to be a String or number or boolean or date etc.
One can't store an object against a key,which i feel is must for NoSql DB.
https://learn.microsoft.com/en-us/rest/api/storageservices/fileservices/understanding-the-table-service-data-model scroll to Property Types
I'm starting on some architecture work for a .Net based social networking application to be hosted on Azure cloud. we are going to be using ASP.NET MVC on the front end.
i would like to consider the options for storage. considering scalability needs and due to the inter-connected nature of the application, SQL azure has been ruled out.
what would be the main considerations in choosing a graph DB such as Sones GraphDB or neo4j which have features specific for a social networking application against using windows azure table storage to achieve the needs.
i'm mostly concerned about development time, cost, ability to leverage existing skills like .NET and reliability of the graph DB platforms and ease of setup and administration.
Graph databases are designed for applications such as social networks. For ease of development, it may be best to start with something like GraphDB. A key advantage over a key-value database is powerful query and traversal capabilities. It would be easy to, for instance, find all occurrences of friends of friends using the GraphDB query syntax.
The benefit of a key-value database service like Azure Table is low cost, minimal administrative overhead and scalability. You can store 500TB of data per Azure storage account and setup accounts in multiple regions. There is no server setup or database administration overhead and the Visual Studio SDK is easy to use. The down side is that graph like query support is not built in and you must index off the Primary Key / Row Key pair. For additional Azure Table design pattern please see https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/