Apache Ignite聽vs聽MongoDB

Need advice about which tool to choose?Ask the StackShare community!

Apache Ignite

67
107
+ 1
19
MongoDB

56.6K
46.3K
+ 1
4.1K
Add tool

Apache Ignite vs MongoDB: What are the differences?

Apache Ignite: An open-source distributed database, caching and processing platform *. It is a memory-centric distributed database, caching, and processing platform for transactional, analytical, and streaming workloads delivering in-memory speeds at petabyte scale; *MongoDB:** The database for giant ideas. MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding.

Apache Ignite can be classified as a tool in the "In-Memory Databases" category, while MongoDB is grouped under "Databases".

Apache Ignite and MongoDB are both open source tools. It seems that MongoDB with 16.5K GitHub stars and 4.13K forks on GitHub has more adoption than Apache Ignite with 2.67K GitHub stars and 1.3K GitHub forks.

According to the StackShare community, MongoDB has a broader approval, being mentioned in 2915 company stacks & 11690 developers stacks; compared to Apache Ignite, which is listed in 4 company stacks and 4 developer stacks.

Advice on Apache Ignite and MongoDB
Needs advice
on
MySQL
and
MongoDB

Hello, I am developing a new project with an internal chat between users. Also, there are complex relationships between the other project entities but I wolud like to build something scalable and fast and right now I am designing the data model. What kind of database would you recommend me to manage all application data? relational like MySQL, no relational like MongoDB or a mixed one? Thank you

See more
Replies (6)
Recommends
PostgreSQL

In MongoDB, a write operation is atomic on the level of a single document, so it's harder to deal with consistency without transactions.

See more
Recommends
MongoDB

MongoDB supports horizontal scaling through Sharding , distributing data across several machines and facilitating high throughput operations with large sets of data. ... Sharding allows you to add additional instances to increase capacity when required

See more
Recommends
ArangoDB

If you are trying with "complex relationships", give a chance to learn ArangoDB and Graph databases. Its database structures allow doing this with faster and simpler queries. The database is not as strict as others and allows arbitrary data. The data model is really like a neural network and you will never need foreign keys tables anymore. In Udemy there is a free course about it to get started.

See more
Kit Ruparel
Recommends
Apache Aurora

The most important question is where are you planning to host? On-premise, or in the cloud.

Particularly if you are planning to host in either AWS or Azure, then your first point of call should be the PaaS (Platform as a Service) databases supplied by these vendors, as you will find yourself requiring a lot less effort to support them, much easier Disaster Recovery options, and also, depending on how PAYG the database is that you use, potentially also much cheaper costs than having a dedicated database server.

Your question regards 'Relational or not' is obviously key, and you need to consider both your required data structure, as well as the ACID requirements of your application model, as well as the non-functional requirements in terms of scalability, resilience, whether you want security authorisation at the highest application tier, or right down to 'row' level in the database, etc. - however please don't fall into the trap of considering 'NoSQL' as being single category. MongoDB, with its document-store type solution is a very different model to key-value-pair stores (like AWS DynamoDB), or column stores (like AWS RedShift) or for more complex data relationships, Entity Graph Stores (like AWS Neptune), to stores designed for tokenisation and text search (ElasticSearch) etc.

Also critical in all this is how many items you believe you need to index by. RDBMS/SQL stores are great for having as many indexes as you want, other than the slow-down in write speed, whereas databases like Amazon DynamoDB provide blisteringly fast read/write performance, but are very limited on key indexing capabilities.

It feels like you have most experience with SQL/RDBMS technologies, so for the simplest learning curve, and if your application fits it, then I'd personally start by looking at AWS Aurora https://aws.amazon.com/rds/aurora/ .

See more
Daniel Mwakanema
Software Developer at Kuunika - Data for Action | 2 upvotes 路 145K views
Recommends
MySQL

FIrstly, it may help if you explain what you mean by "complex relationships between project entities". Secondly, you can build a fast and scalable solution using either. With that said however, the data sounds relational so I would recommend MySQL.

See more
RODIALSON Tojo
FullStack Developer / CTO at O2Development | 2 upvotes 路 145.1K views
Recommends
MySQL

I think, Its depend of your project type and your skills. MySQL is good and simple for maintenance but MongoDB need more skills and knowledge. If you work on little project, use MySQL. For your project type, MySQL is enough after you can migrate with PostgreSQL

See more
View all (6)
Prithvi Singh
Application Developer at Montaigne Smart Business Solutions | 8 upvotes 路 196K views
Needs advice
on
PostgreSQL
MySQL
and
MongoDB

I am going to work on a real estate project and have to decide on a database. Now, SQL databases can be very efficient if appropriately designed. More relations between the data and less redundancy. But with a #NoSQL database, the development time is reduced, and it is easy to query. Since this is my first time working on the real estate domain, I would like to pick a database that would be efficient in the long run.

See more
Replies (4)
Aric Fedida
Founder, CTO at ASK Technologies Inc | 15 upvotes 路 187.9K views
Recommends
PostgreSQL

I recommend PostgreSQL as it鈥檚 the most powerful out of the 3 databases you mentioned. It supports JSON objects so you can mimic the MongoDB functionality, but I would also argue that SQL is actually quite powerful and in many cases significantly easier to work with than with NoSQL databases.

Stay away from foreign keys, keep it fast and simple. Define your data structures well in advance. Try to model your data structures based on your system鈥檚 vision; based on where it鈥檚 going and not based solely on what you currently need it to do. This will help you avoid drastic changes to your database after your system is launched. Populate the database with fake data and run tests. PostgreSQL allows you to create Views from multiple tables. Try to create those views and make sure you can easily create useful views from multiple tables. Run an Explain on those view queries to make sure you created your indexes correctly. Make sure it鈥檚 fast!

See more
Matthew Rothstein
Recommends
PostgreSQL

Any of those three databases are going to be efficient, scalable, and reliable in the long term if you configure and use them correctly. They all also have solid hosting solutions.

All things being equal, I would agree with other posters that Postgres is my preference among the three, but there are caveats.

MongoDB and MySQL have better support for mutli-region replication in your big three cloud environments. Azure recently bought Citus Data, which was a best-in-class Postgres replication solution, so they might be the only one I trust to provide cross-region replication at the moment.

If you have a single region deployment and are on AWS, I can't recommend Aurora Postgres highly enough. It's a very good implementation and extremely performant.

See more
Danilo Kaltner
Recommends
PostgreSQL

That really depends of where do you see you application in the long run. On any application, any of those choices are excellent. You could argue about good support on JSON binaries, but even MySQL has an excellent support for that on the latest versions.

On the long run, when your application gets hundreds of thousands of requests per second, you might start thinking about how many inputs you will have in the database compared to the outputs. PostgresSQL it鈥檚 excellent at giving you outputs, but table corruption can happen when you start receiving this massive number of inputs (Which was the reason Uber switched from Postgres to MySQL)

On our OPS Platform at CTO.ai , we decided to use Postgres, because we need a reliable and agile way to send the output to our users, so that was out best choice in the long run for our product.

See more
Josh Dzielak
Co-Founder & CTO at Orbit | 4 upvotes 路 185.2K views
Recommends
PostgreSQL

I'll second another piece of advice. Postgresql's JSON columns are a dream when it comes to productivity and I use them frequently with our Rails application. In these cases, no migration is required to change schema. We store payloads with dozens or hundreds of keys and performance has not been an issue. We also have a lot of relational tables, so the joins we get with SQL are very important to us and hard to replicate with a NoQL solution.

See more
View all (4)
Needs advice
on
PostgreSQL
and
MongoDB

I am one of those who believes that MongoDB can be used for everything, this thanks to the advertising of MongoDB.

We are creating an e-commerce platform, we know that it has many relationships, but with MongoDB we can avoid some, but in the end, some relationships have to exist.

A single developer to create two native applications in Flutter, a web application with React, create the backend with multiple microservices hosted with Google Cloud Run. PostgreSQL can be heavy because it should be used with an ORM, on the contrary, with MongoDB you can avoid some relationships and avoid ORM / ODM.

We need advice from someone who has the experience and has had to choose between these two databases for an e-commerce site.

See more
Replies (4)
Recommends
PostgreSQL

The real question here is not about the technology but rather your real needs and your data. Do you need to manage data that has core concepts and relations ? (such as a family, with parents and children) or do you need to manage a basic collection of similar data (such as blog entries)? PostgreSQL is definitely a relational database for managing entities and their relationships whereas MongoDB (I may be strongly opinionated here ;-) ) is more targeted at managing collection of entities (such as the blog entries). For an e-commerce site (with some products, products categories, user ratings and comments, prices, bundles...) I would go for PostgreSQL as it will support/guide you in creating a structured data set with all your products, organized in categories and with user ratings/comments attached to them. HTH

See more
Valeriy Bykanov
Founder, CEO at X1 Group | 3 upvotes 路 124.8K views
Recommends
at

Had exactly the same question when selecting data storage for our new product. Not e-commerce though, rather interactive and content-focused HR SaaS for SME.

The key arguments for PostgreSQL

  • It gives you the opportunity to use relationships where you really need it and just go with key-value tables where you don't.

  • With Jsonb datatype you can store documents/objects/arrays as JSON then use JSON elements in queries and even indexes.

  • There are more tools/integrations working with PostgreSQL which you can use out of the box, e.g. Hasura

See more
Dami谩n Gil
Advisor at Empresa En Crecimiento | 3 upvotes 路 123.8K views
Recommends
MongoDB

I am in your spot, exactly. A few months ago, I had decided to use Postgres because since its version 9 it showed a lot of progress for being a high-availability database. However, frankly, I didn't want to model statically all data, since I have several distinct schemas (like for different product types) and I wanted some flexibility to add or remove as I saw fit. One of the main challenges with analyzing a NoSQL database being familiar in the SQL ways, is that it's easy to look for "analogies" for what makes SQL useful, like relationship enforcing, transactions and the cascading effect on deletes, updates and inserts, and that limit your vision a lot when analyzing a tool like Mongo, especially in a micro-services pattern. Now-a-days, I really found my solution in Mongo. Not just because of it being NoSQL, but because all of the support I find in the NodeJS community through packages and utilities that make it dead easy to use it for several use-cases. Whatever Postgres offers, Mongo does it a little easier and better, like text search and geo-queries. What you need to see is to model your data in a way that makes sense with Mongo. For instance, I've got a User service that has all auth related information of a user. But then, I have the same user in the Profile service, with the same id, but totally different fields. You have two de facto ways to connect data, by reference and embedding, which in Ecommerce, both have big uses. Like using references to relate a User to a Profile, and an embed to relate a Product to an Order. There's even a third, albeit a little more "manual" implementation here, the graph relationship in which you can model data, in which you can easily model event-driven documents, like a Purchase that goes from "a customer" to "a store", which you can later use for much easier and deep analytics than with the classical SQL stance. MariaDB has it readily available, and also has many improvements over MySQL and Postgres, especially for NoSQL features and scalability. Sadly it is just seen as a MySQL clone, but it offers more than that (although its documentation could be improved). Using Mongo in a micro-service environment is even better because your models can be smaller, meaning less burden on relationships, although you do compensate with a bit of duplication, but a well-designed schema will have minimal impact on that. Whatever tool might do the job, but I want to cheer on the newer generation. Hope it helps.

See more
View all (4)
Decisions about Apache Ignite and MongoDB
Omran Jamal
CTO & Co-founder at Bonton Connect | 4 upvotes 路 171.9K views

We actually use both Mongo and SQL databases in production. Mongo excels in both speed and developer friendliness when it comes to geospatial data and queries on the geospatial data, but we also like ACID compliance hence most of our other data (except on-site logs) are stored in a SQL Database (MariaDB for now)

See more
Kyle Harrison
Web Application Developer at Fortinet | 11 upvotes 路 248.3K views

MySQL has a lot of strengths working for it. It's simple and easy to set up and use. It's JSON engine is also really good these days. Mongo is also simple to setup and use, and it's speed as a document-object storage engine is first class.

Where Postgres has both beat is in it's combining of all of the features that make both MySQL and Mongo great, while adding on enterprise grade level scalability and replication. It's Postgres' stability and robustness, while still fulfilling the roles of it's contemporaries extremely well that edge Postgre for me.

See more

When I was new with web development, I was using PHP for backend and MySQL for database. But after improving my JS skills, I chosen Node.js. Because of too many reasons including npm, express, community, fast coding and etc. MongoDB is so good for using with Node.js. If your JS skills are enough good, I recommend to migrate to Node.js and MongoDB.

See more
Get Advice from developers at your company using Private StackShare. Sign up for Private StackShare.
Learn More
Pros of Apache Ignite
Pros of MongoDB
  • 3
    Written in java. runs on jvm
  • 3
    Free
  • 2
    Load balancing
  • 2
    High Avaliability
  • 2
    Rest interface
  • 2
    Sql query support in cluster wide
  • 1
    Multiple client language support
  • 1
    Better Documentation
  • 1
    Distributed compute
  • 1
    Distributed Locking
  • 1
    Easy to use
  • 823
    Document-oriented storage
  • 589
    No sql
  • 545
    Ease of use
  • 463
    Fast
  • 405
    High performance
  • 253
    Free
  • 214
    Open source
  • 178
    Flexible
  • 140
    Replication & high availability
  • 108
    Easy to maintain
  • 40
    Querying
  • 36
    Easy scalability
  • 35
    Auto-sharding
  • 34
    High availability
  • 30
    Map/reduce
  • 26
    Document database
  • 24
    Easy setup
  • 24
    Full index support
  • 15
    Reliable
  • 14
    Fast in-place updates
  • 13
    Agile programming, flexible, fast
  • 11
    No database migrations
  • 7
    Enterprise
  • 7
    Easy integration with Node.Js
  • 5
    Enterprise Support
  • 4
    Great NoSQL DB
  • 3
    Aggregation Framework
  • 3
    Support for many languages through different drivers
  • 3
    Drivers support is good
  • 2
    Schemaless
  • 2
    Fast
  • 2
    Awesome
  • 2
    Managed service
  • 2
    Easy to Scale
  • 1
    Consistent

Sign up to add or upvote prosMake informed product decisions

Cons of Apache Ignite
Cons of MongoDB
    Be the first to leave a con
    • 5
      Very slowly for connected models that require joins
    • 3
      Not acid compliant
    • 1
      Proprietary query language

    Sign up to add or upvote consMake informed product decisions

    No Stats

    What is Apache Ignite?

    It is a memory-centric distributed database, caching, and processing platform for transactional, analytical, and streaming workloads delivering in-memory speeds at petabyte scale

    What is MongoDB?

    MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding.

    Need advice about which tool to choose?Ask the StackShare community!

    What companies use Apache Ignite?
    What companies use MongoDB?
    See which teams inside your own company are using Apache Ignite or MongoDB.
    Sign up for Private StackShareLearn More

    Sign up to get full access to all the companiesMake informed product decisions

    What tools integrate with Apache Ignite?
    What tools integrate with MongoDB?

    Sign up to get full access to all the tool integrationsMake informed product decisions

    Blog Posts

    Dec 8 2020 at 5:50PM

    DigitalOcean

    +11
    2
    1701
    +29
    15
    11059
    +34
    29
    40302
    +30
    25
    14887
    What are some alternatives to Apache Ignite and MongoDB?
    Redis
    Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
    MySQL
    The MySQL software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software.
    Hazelcast
    With its various distributed data structures, distributed caching capabilities, elastic nature, memcache support, integration with Spring and Hibernate and more importantly with so many happy users, Hazelcast is feature-rich, enterprise-ready and developer-friendly in-memory data grid solution.
    Apache Spark
    Spark is a fast and general processing engine compatible with Hadoop data. It can run in Hadoop clusters through YARN or Spark's standalone mode, and it can process data in HDFS, HBase, Cassandra, Hive, and any Hadoop InputFormat. It is designed to perform both batch processing (similar to MapReduce) and new workloads like streaming, interactive queries, and machine learning.
    Elasticsearch
    Elasticsearch is a distributed, RESTful search and analytics engine capable of storing data and searching it in near real time. Elasticsearch, Kibana, Beats and Logstash are the Elastic Stack (sometimes called the ELK Stack).
    See all alternatives
    How developers use Apache Ignite and MongoDB
    Tarun Singh uses
    MongoDB

    Used MongoDB as primary database. It holds trip data of NYC taxis for the year 2013. It is a huge dataset and it's primary feature is geo coordinates with pickup and drop off locations. Also used MongoDB's map reduce to process this large dataset for aggregation. This aggregated result was then used to show visualizations.

    Trello uses
    MongoDB

    MongoDB fills our more traditional database needs. We knew we wanted Trello to be blisteringly fast. One of the coolest and most performance-obsessed teams we know is our next-door neighbor and sister company StackExchange. Talking to their dev lead David at lunch one day, I learned that even though they use SQL Server for data storage, they actually primarily store a lot of their data in a denormalized format for performance, and normalize only when they need to.

    Foursquare uses
    MongoDB

    Nearly all of our backend storage is on MongoDB. This has also worked out pretty well. It's enabled us to scale up faster/easier than if we had rolled our own solution on top of PostgreSQL (which we were using previously). There have been a few roadbumps along the way, but the team at 10gen has been a big help with thing.

    AngeloR uses
    MongoDB

    We are testing out MongoDB at the moment. Currently we are only using a small EC2 setup for a delayed job queue backed by agenda. If it works out well we might look to see where it could become a primary document storage engine for us.

    Rohith Nandakumar uses
    MongoDB

    Because you don't know what data you will be querying for. Perfectly suited for rapid prototyping. Altering tables in traditional, relational DBMS is painfully expensive and slow.

    Performance is not great though. Ah who cares!