Alternatives to ArangoDB logo

Alternatives to ArangoDB

Neo4j, MongoDB, PostgreSQL, Cassandra, and OrientDB are the most popular alternatives and competitors to ArangoDB.
276
442
+ 1
192

What is ArangoDB and what are its top alternatives?

ArangoDB is a multi-model database system that allows users to efficiently store and query data using different data models: key-value, document, and graph. It supports ACID transactions, distributed computing, and scalable sharding, making it suitable for a wide range of use cases. However, ArangoDB may have a steep learning curve for beginners, and some users may find its query language and data modeling approach to be complex.

  1. MongoDB: MongoDB is a popular document-oriented database that is known for its scalability, flexibility, and ease of use. It supports automatic sharding, high availability, and horizontal scaling, making it a good alternative to ArangoDB. However, MongoDB lacks native graph database capabilities, which may be a limitation for some users.
  2. Neo4j: Neo4j is a graph database that is optimized for handling complex relationships and graph queries. It provides a powerful query language (Cypher) and supports ACID transactions, making it a strong alternative to ArangoDB for graph-related use cases. However, Neo4j may be less suitable for hybrid data models compared to ArangoDB.
  3. Couchbase: Couchbase is a distributed NoSQL database that offers high performance, scalability, and built-in caching capabilities. It supports key-value and document data models, making it a versatile alternative to ArangoDB. However, Couchbase may have limitations in terms of graph database functionalities.
  4. Cassandra: Cassandra is a highly scalable and fault-tolerant distributed database system that is designed for handling large amounts of data across multiple nodes. It provides tunable consistency levels, decentralized architecture, and high availability, making it a robust alternative to ArangoDB for big data applications. However, Cassandra may lack some of the features offered by ArangoDB in terms of data modeling and query flexibility.
  5. Redis: Redis is an in-memory data structure store that is commonly used for caching, real-time analytics, and messaging applications. It supports a wide range of data structures, such as strings, lists, sets, and sorted sets, making it a fast and lightweight alternative to ArangoDB for specific use cases. However, Redis may not be suitable for complex data processing and querying requirements.
  6. Amazon DynamoDB: Amazon DynamoDB is a fully managed NoSQL database service that offers seamless scalability, high availability, and low latency. It supports key-value and document data models, making it a reliable alternative to ArangoDB for cloud-native applications. However, DynamoDB may have limitations in terms of query flexibility and advanced data modeling features compared to ArangoDB.
  7. RethinkDB: RethinkDB is a distributed database system that is optimized for real-time applications and collaborative workloads. It provides automatic sharding, change feeds, and query language (ReQL) for building interactive applications, making it a compelling alternative to ArangoDB for certain use cases. However, RethinkDB may have limitations in terms of scalability and community support.
  8. PostgreSQL: PostgreSQL is a powerful open-source relational database system that offers a wide range of features, such as ACID compliance, full-text search, and JSON support. It supports both SQL and NoSQL capabilities, making it a versatile alternative to ArangoDB for diverse workloads. However, PostgreSQL may have limitations in terms of scalability and performance compared to ArangoDB for specific use cases.
  9. HBase: HBase is a distributed column-oriented database that is optimized for handling large amounts of sparse data. It provides low latency, strong consistency, and linear scalability, making it a suitable alternative to ArangoDB for certain big data applications. However, HBase may have limitations in terms of complex querying and data modeling capabilities compared to ArangoDB.
  10. JanusGraph: JanusGraph is an open-source distributed graph database that is optimized for handling complex graph relationships and OLAP workloads. It provides support for a wide range of storage backends, such as Apache HBase, Google Cloud Bigtable, and Cassandra, making it a flexible alternative to ArangoDB for graph-related use cases. However, JanusGraph may have limitations in terms of query language support and ease of use compared to ArangoDB.

Top Alternatives to ArangoDB

  • Neo4j
    Neo4j

    Neo4j stores data in nodes connected by directed, typed relationships with properties on both, also known as a Property Graph. It is a high performance graph store with all the features expected of a mature and robust database, like a friendly query language and ACID transactions. ...

  • MongoDB
    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. ...

  • PostgreSQL
    PostgreSQL

    PostgreSQL is an advanced object-relational database management system that supports an extended subset of the SQL standard, including transactions, foreign keys, subqueries, triggers, user-defined types and functions. ...

  • Cassandra
    Cassandra

    Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL. ...

  • OrientDB
    OrientDB

    It is an open source NoSQL database management system written in Java. It is a Multi-model database, supporting graph, document, key/value, and object models, but the relationships are managed as in graph databases with direct connections between records. ...

  • MySQL
    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. ...

  • Elasticsearch
    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). ...

  • Dgraph
    Dgraph

    Dgraph's goal is to provide Google production level scale and throughput, with low enough latency to be serving real time user queries, over terabytes of structured data. Dgraph supports GraphQL-like query syntax, and responds in JSON and Protocol Buffers over GRPC and HTTP. ...

ArangoDB alternatives & related posts

Neo4j logo

Neo4j

1.2K
1.4K
352
The world’s leading Graph Database
1.2K
1.4K
+ 1
352
PROS OF NEO4J
  • 70
    Cypher – graph query language
  • 61
    Great graphdb
  • 33
    Open source
  • 31
    Rest api
  • 27
    High-Performance Native API
  • 23
    ACID
  • 21
    Easy setup
  • 17
    Great support
  • 11
    Clustering
  • 9
    Hot Backups
  • 8
    Great Web Admin UI
  • 7
    Powerful, flexible data model
  • 7
    Mature
  • 6
    Embeddable
  • 5
    Easy to Use and Model
  • 4
    Best Graphdb
  • 4
    Highly-available
  • 2
    It's awesome, I wanted to try it
  • 2
    Great onboarding process
  • 2
    Great query language and built in data browser
  • 2
    Used by Crunchbase
CONS OF NEO4J
  • 9
    Comparably slow
  • 4
    Can't store a vertex as JSON
  • 1
    Doesn't have a managed cloud service at low cost

related Neo4j posts

Shared insights
on
Neo4jNeo4jKafkaKafkaMySQLMySQL

Hello Stackshare. I'm currently doing some research on real-time reporting and analytics architectures. We have a use case where 1million+ records of users, 4million+ activities, and messages that we want to report against. The start was to present it directly from MySQL, which didn't go well and puts a heavy load on the database. Anybody can suggest something where we feed the data and can report in realtime? Read some articles about ElasticSearch and Kafka https://medium.com/@D11Engg/building-scalable-real-time-analytics-alerting-and-anomaly-detection-architecture-at-dream11-e20edec91d33 EDIT: also considering Neo4j

See more
Stephen Gheysens
Lead Solutions Engineer at Inscribe · | 7 upvotes · 462.5K views

Google Maps lets "property owners and their authorized representatives" upload indoor maps, but this appears to lack navigation ("wayfinding").

MappedIn is a platform and has SDKs for building indoor mapping experiences (https://www.mappedin.com/) and ESRI ArcGIS also offers some indoor mapping tools (https://www.esri.com/en-us/arcgis/indoor-gis/overview). Finally, there used to be a company called LocusLabs that is now a part of Atrius and they were often integrated into airlines' apps to provide airport maps with wayfinding (https://atrius.com/solutions/personal-experiences/personal-wayfinder/).

I previously worked at Mapbox and while I believe that it's a great platform for building map-based experiences, they don't have any simple solutions for indoor wayfinding. If I were doing this for fun as a side-project and prioritized saving money over saving time, here is what I would do:

  • Create a graph-based dataset representing the walking paths around your university, where nodes/vertexes represent the intersections of paths, and edges represent paths (literally paths outside, hallways, short path segments that represent entering rooms). You could store this in a hosted graph-based database like Neo4j, Amazon Neptune , or Azure Cosmos DB (with its Gremlin API) and use built-in "shortest path" queries, or deploy a PostgreSQL service with pgRouting.

  • Add two properties to each edge: one property for the distance between its nodes (libraries like @turf/helpers will have a distance function if you have the latitude & longitude of each node), and another property estimating the walking time (based on the distance). Once you have these values saved in a graph-based format, you should be able to easily query and find the data representation of paths between two points.

  • At this point, you'd have the routing problem solved and it would come down to building a UI. Mapbox arguably leads the industry in developer tools for custom map experiences. You could convert your nodes/edges to GeoJSON, then either upload to Mapbox and create a Tileset to visualize the paths, or add the GeoJSON to the map on the fly.

*You might be able to use open source routing tools like OSRM (https://github.com/Project-OSRM/osrm-backend/issues/6257) or Graphhopper (instead of a custom graph database implementation), but it would likely be more involved to maintain these services.

See more
MongoDB logo

MongoDB

92.5K
79.8K
4.1K
The database for giant ideas
92.5K
79.8K
+ 1
4.1K
PROS OF MONGODB
  • 827
    Document-oriented storage
  • 593
    No sql
  • 553
    Ease of use
  • 464
    Fast
  • 410
    High performance
  • 257
    Free
  • 218
    Open source
  • 180
    Flexible
  • 145
    Replication & high availability
  • 112
    Easy to maintain
  • 42
    Querying
  • 39
    Easy scalability
  • 38
    Auto-sharding
  • 37
    High availability
  • 31
    Map/reduce
  • 27
    Document database
  • 25
    Easy setup
  • 25
    Full index support
  • 16
    Reliable
  • 15
    Fast in-place updates
  • 14
    Agile programming, flexible, fast
  • 12
    No database migrations
  • 8
    Easy integration with Node.Js
  • 8
    Enterprise
  • 6
    Enterprise Support
  • 5
    Great NoSQL DB
  • 4
    Support for many languages through different drivers
  • 3
    Schemaless
  • 3
    Aggregation Framework
  • 3
    Drivers support is good
  • 2
    Fast
  • 2
    Managed service
  • 2
    Easy to Scale
  • 2
    Awesome
  • 2
    Consistent
  • 1
    Good GUI
  • 1
    Acid Compliant
CONS OF MONGODB
  • 6
    Very slowly for connected models that require joins
  • 3
    Not acid compliant
  • 2
    Proprietary query language

related MongoDB posts

Shared insights
on
Node.jsNode.jsGraphQLGraphQLMongoDBMongoDB

I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery

For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:

  1. Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have

  2. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.

  3. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website

See more
Vaibhav Taunk
Team Lead at Technovert · | 31 upvotes · 4M views

I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.

See more
PostgreSQL logo

PostgreSQL

97K
81.2K
3.5K
A powerful, open source object-relational database system
97K
81.2K
+ 1
3.5K
PROS OF POSTGRESQL
  • 763
    Relational database
  • 510
    High availability
  • 439
    Enterprise class database
  • 383
    Sql
  • 304
    Sql + nosql
  • 173
    Great community
  • 147
    Easy to setup
  • 131
    Heroku
  • 130
    Secure by default
  • 113
    Postgis
  • 50
    Supports Key-Value
  • 48
    Great JSON support
  • 34
    Cross platform
  • 33
    Extensible
  • 28
    Replication
  • 26
    Triggers
  • 23
    Multiversion concurrency control
  • 23
    Rollback
  • 21
    Open source
  • 18
    Heroku Add-on
  • 17
    Stable, Simple and Good Performance
  • 15
    Powerful
  • 13
    Lets be serious, what other SQL DB would you go for?
  • 11
    Good documentation
  • 9
    Scalable
  • 8
    Intelligent optimizer
  • 8
    Free
  • 8
    Reliable
  • 7
    Transactional DDL
  • 7
    Modern
  • 6
    One stop solution for all things sql no matter the os
  • 5
    Faster Development
  • 5
    Relational database with MVCC
  • 4
    Full-Text Search
  • 4
    Developer friendly
  • 3
    Great DB for Transactional system or Application
  • 3
    Free version
  • 3
    Excellent source code
  • 3
    Relational datanbase
  • 3
    search
  • 3
    Open-source
  • 2
    Full-text
  • 2
    Text
  • 1
    Multiple procedural languages supported
  • 1
    Can handle up to petabytes worth of size
  • 0
    Native
CONS OF POSTGRESQL
  • 10
    Table/index bloatings

related PostgreSQL posts

Simon Reymann
Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 10M views

Our whole DevOps stack consists of the following tools:

  • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
  • Respectively Git as revision control system
  • SourceTree as Git GUI
  • Visual Studio Code as IDE
  • CircleCI for continuous integration (automatize development process)
  • Prettier / TSLint / ESLint as code linter
  • SonarQube as quality gate
  • Docker as container management (incl. Docker Compose for multi-container application management)
  • VirtualBox for operating system simulation tests
  • Kubernetes as cluster management for docker containers
  • Heroku for deploying in test environments
  • nginx as web server (preferably used as facade server in production environment)
  • SSLMate (using OpenSSL) for certificate management
  • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
  • PostgreSQL as preferred database system
  • Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

  • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
  • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
  • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
  • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
  • Scalability: All-in-one framework for distributed systems.
  • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
See more
Jeyabalaji Subramanian

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Cassandra logo

Cassandra

3.6K
3.5K
507
A partitioned row store. Rows are organized into tables with a required primary key.
3.6K
3.5K
+ 1
507
PROS OF CASSANDRA
  • 119
    Distributed
  • 98
    High performance
  • 81
    High availability
  • 74
    Easy scalability
  • 53
    Replication
  • 26
    Reliable
  • 26
    Multi datacenter deployments
  • 10
    Schema optional
  • 9
    OLTP
  • 8
    Open source
  • 2
    Workload separation (via MDC)
  • 1
    Fast
CONS OF CASSANDRA
  • 3
    Reliability of replication
  • 1
    Size
  • 1
    Updates

related Cassandra posts

Thierry Schellenbach
Shared insights
on
GolangGolangPythonPythonCassandraCassandra
at

After years of optimizing our existing feed technology, we decided to make a larger leap with 2.0 of Stream. While the first iteration of Stream was powered by Python and Cassandra, for Stream 2.0 of our infrastructure we switched to Go.

The main reason why we switched from Python to Go is performance. Certain features of Stream such as aggregation, ranking and serialization were very difficult to speed up using Python.

We’ve been using Go since March 2017 and it’s been a great experience so far. Go has greatly increased the productivity of our development team. Not only has it improved the speed at which we develop, it’s also 30x faster for many components of Stream. Initially we struggled a bit with package management for Go. However, using Dep together with the VG package contributed to creating a great workflow.

Go as a language is heavily focused on performance. The built-in PPROF tool is amazing for finding performance issues. Uber’s Go-Torch library is great for visualizing data from PPROF and will be bundled in PPROF in Go 1.10.

The performance of Go greatly influenced our architecture in a positive way. With Python we often found ourselves delegating logic to the database layer purely for performance reasons. The high performance of Go gave us more flexibility in terms of architecture. This led to a huge simplification of our infrastructure and a dramatic improvement of latency. For instance, we saw a 10 to 1 reduction in web-server count thanks to the lower memory and CPU usage for the same number of requests.

#DataStores #Databases

See more
Thierry Schellenbach
Shared insights
on
RedisRedisCassandraCassandraRocksDBRocksDB
at

1.0 of Stream leveraged Cassandra for storing the feed. Cassandra is a common choice for building feeds. Instagram, for instance started, out with Redis but eventually switched to Cassandra to handle their rapid usage growth. Cassandra can handle write heavy workloads very efficiently.

Cassandra is a great tool that allows you to scale write capacity simply by adding more nodes, though it is also very complex. This complexity made it hard to diagnose performance fluctuations. Even though we had years of experience with running Cassandra, it still felt like a bit of a black box. When building Stream 2.0 we decided to go for a different approach and build Keevo. Keevo is our in-house key-value store built upon RocksDB, gRPC and Raft.

RocksDB is a highly performant embeddable database library developed and maintained by Facebook’s data engineering team. RocksDB started as a fork of Google’s LevelDB that introduced several performance improvements for SSD. Nowadays RocksDB is a project on its own and is under active development. It is written in C++ and it’s fast. Have a look at how this benchmark handles 7 million QPS. In terms of technology it’s much more simple than Cassandra.

This translates into reduced maintenance overhead, improved performance and, most importantly, more consistent performance. It’s interesting to note that LinkedIn also uses RocksDB for their feed.

#InMemoryDatabases #DataStores #Databases

See more
OrientDB logo

OrientDB

75
107
14
An open source NoSQL database management system
75
107
+ 1
14
PROS OF ORIENTDB
  • 4
    Great graphdb
  • 2
    Great support
  • 2
    Open source
  • 1
    Multi-Model/Paradigm
  • 1
    ACID
  • 1
    Highly-available
  • 1
    Performance
  • 1
    Embeddable
  • 1
    Rest api
CONS OF ORIENTDB
  • 4
    Unstable

related OrientDB posts

We have an in-house build experiment management system. We produce samples as input to the next step, which then could produce 1 sample(1-1) and many samples (1 - many). There are many steps like this. So far, we are tracking genealogy (limited tracking) in the MySQL database, which is becoming hard to trace back to the original material or sample(I can give more details if required). So, we are considering a Graph database. I am requesting advice from the experts.

  1. Is a graph database the right choice, or can we manage with RDBMS?
  2. If RDBMS, which RDMS, which feature, or which approach could make this manageable or sustainable
  3. If Graph database(Neo4j, OrientDB, Azure Cosmos DB, Amazon Neptune, ArangoDB), which one is good, and what are the best practices?

I am sorry that this might be a loaded question.

See more
MySQL logo

MySQL

123.8K
104.6K
3.7K
The world's most popular open source database
123.8K
104.6K
+ 1
3.7K
PROS OF MYSQL
  • 800
    Sql
  • 679
    Free
  • 562
    Easy
  • 528
    Widely used
  • 489
    Open source
  • 180
    High availability
  • 160
    Cross-platform support
  • 104
    Great community
  • 78
    Secure
  • 75
    Full-text indexing and searching
  • 25
    Fast, open, available
  • 16
    SSL support
  • 15
    Reliable
  • 14
    Robust
  • 8
    Enterprise Version
  • 7
    Easy to set up on all platforms
  • 2
    NoSQL access to JSON data type
  • 1
    Relational database
  • 1
    Easy, light, scalable
  • 1
    Sequel Pro (best SQL GUI)
  • 1
    Replica Support
CONS OF MYSQL
  • 16
    Owned by a company with their own agenda
  • 3
    Can't roll back schema changes

related MySQL posts

Nick Rockwell
SVP, Engineering at Fastly · | 46 upvotes · 3.6M views

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

See more
Tim Abbott

We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

I can't recommend it highly enough.

See more
Elasticsearch logo

Elasticsearch

34.3K
26.7K
1.6K
Open Source, Distributed, RESTful Search Engine
34.3K
26.7K
+ 1
1.6K
PROS OF ELASTICSEARCH
  • 328
    Powerful api
  • 315
    Great search engine
  • 231
    Open source
  • 214
    Restful
  • 200
    Near real-time search
  • 98
    Free
  • 85
    Search everything
  • 54
    Easy to get started
  • 45
    Analytics
  • 26
    Distributed
  • 6
    Fast search
  • 5
    More than a search engine
  • 4
    Great docs
  • 4
    Awesome, great tool
  • 3
    Highly Available
  • 3
    Easy to scale
  • 2
    Potato
  • 2
    Document Store
  • 2
    Great customer support
  • 2
    Intuitive API
  • 2
    Nosql DB
  • 2
    Great piece of software
  • 2
    Reliable
  • 2
    Fast
  • 2
    Easy setup
  • 1
    Open
  • 1
    Easy to get hot data
  • 1
    Github
  • 1
    Elaticsearch
  • 1
    Actively developing
  • 1
    Responsive maintainers on GitHub
  • 1
    Ecosystem
  • 1
    Not stable
  • 1
    Scalability
  • 0
    Community
CONS OF ELASTICSEARCH
  • 7
    Resource hungry
  • 6
    Diffecult to get started
  • 5
    Expensive
  • 4
    Hard to keep stable at large scale

related Elasticsearch posts

Tim Abbott

We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

I can't recommend it highly enough.

See more
Tymoteusz Paul
Devops guy at X20X Development LTD · | 23 upvotes · 8.9M views

Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

See more
Dgraph logo

Dgraph

125
220
9
Fast, Distributed Graph DB
125
220
+ 1
9
PROS OF DGRAPH
  • 3
    Graphql as a query language is nice if you like apollo
  • 2
    Easy set up
  • 2
    Low learning curve
  • 1
    Open Source
  • 1
    High Performance
CONS OF DGRAPH
    Be the first to leave a con

    related Dgraph posts