Alternatives to Hazelcast logo

Alternatives to Hazelcast

Redis, Apache Spark, Cassandra, Memcached, and Apache Ignite are the most popular alternatives and competitors to Hazelcast.
348
471
+ 1
59

What is Hazelcast and what are its top alternatives?

Hazelcast is an open-source in-memory data grid and compute platform that provides distributed caching, distributed data structures, and event processing capabilities. It is known for its high-performance and scalability, allowing users to easily scale their applications by distributing data across multiple nodes. However, one limitation of Hazelcast is its complexity and steep learning curve for new users.

  1. Redis: Redis is an open-source, in-memory data structure store that can be used as a database, cache, and message broker. Key features include data replication, high availability, and support for various data types. Pros include its simplicity, speed, and versatility. Cons include limited scalability compared to Hazelcast.
  2. Apache Ignite: Apache Ignite is an in-memory computing platform that provides data caching, distributed computing, and streaming analytics capabilities. Key features include distributed SQL queries, ACID transactions, and machine learning support. Pros include its SQL compatibility and machine learning integration. Cons include its complexity and resource requirements.
  3. Memcached: Memcached is a high-performance, in-memory key-value store that is commonly used for caching web data. Key features include simplicity, speed, and support for multiple languages. Pros include its simplicity and speed. Cons include lack of durability and persistence compared to Hazelcast.
  4. GridGain: GridGain is an in-memory computing platform built on Apache Ignite that offers additional features such as data grid management, persistence, and security. Key features include scalability, durability, and security. Pros include its integration with Apache Ignite and enterprise-grade features. Cons include its complexity and cost.
  5. Coherence: Oracle Coherence is an in-memory data grid platform that provides distributed caching and data processing capabilities. Key features include data partitioning, event processing, and transaction management. Pros include its integration with Oracle products and enterprise-grade features. Cons include its cost and limited community support.
  6. Infinispan: Infinispan is an open-source, distributed in-memory data grid platform that offers distributed caching and data processing capabilities. Key features include data replication, partitioning, and transaction support. Pros include its performance and scalability. Cons include its documentation and learning curve.
  7. Couchbase: Couchbase is a distributed NoSQL database that offers in-memory caching, data replication, and full-text search capabilities. Key features include built-in query language, mobile synchronization, and cloud integration. Pros include its flexibility and built-in querying capabilities. Cons include its complexity for simple caching use cases.
  8. Tarantool: Tarantool is an in-memory database and application server that offers support for Lua scripting, data replication, and high availability. Key features include Lua scripting engine, sharding, and automatic failover. Pros include its speed and flexibility. Cons include its learning curve for Lua scripting.
  9. GemFire: Pivotal GemFire is an in-memory data grid platform that provides distributed caching, data processing, and event streaming capabilities. Key features include data replication, partitioning, and event processing. Pros include its scalability and performance. Cons include its complexity and cost.
  10. Aerospike: Aerospike is a distributed NoSQL database that offers in-memory caching, high availability, and strong consistency capabilities. Key features include data durability, hybrid memory architecture, and support for flash storage. Pros include its speed and high availability. Cons include its limited feature set compared to Hazelcast.

Top Alternatives to Hazelcast

  • Redis
    Redis

    Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. ...

  • Apache Spark
    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. ...

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

  • Memcached
    Memcached

    Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering. ...

  • Apache Ignite
    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 ...

  • RabbitMQ
    RabbitMQ

    RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received. ...

  • Kafka
    Kafka

    Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design. ...

  • Ehcache
    Ehcache

    Ehcache is an open source, standards-based cache for boosting performance, offloading your database, and simplifying scalability. It's the most widely-used Java-based cache because it's robust, proven, and full-featured. Ehcache scales from in-process, with one or more nodes, all the way to mixed in-process/out-of-process configurations with terabyte-sized caches. ...

Hazelcast alternatives & related posts

Redis logo

Redis

58.6K
45.1K
3.9K
Open source (BSD licensed), in-memory data structure store
58.6K
45.1K
+ 1
3.9K
PROS OF REDIS
  • 886
    Performance
  • 542
    Super fast
  • 513
    Ease of use
  • 444
    In-memory cache
  • 324
    Advanced key-value cache
  • 194
    Open source
  • 182
    Easy to deploy
  • 164
    Stable
  • 155
    Free
  • 121
    Fast
  • 42
    High-Performance
  • 40
    High Availability
  • 35
    Data Structures
  • 32
    Very Scalable
  • 24
    Replication
  • 22
    Great community
  • 22
    Pub/Sub
  • 19
    "NoSQL" key-value data store
  • 16
    Hashes
  • 13
    Sets
  • 11
    Sorted Sets
  • 10
    NoSQL
  • 10
    Lists
  • 9
    Async replication
  • 9
    BSD licensed
  • 8
    Bitmaps
  • 8
    Integrates super easy with Sidekiq for Rails background
  • 7
    Keys with a limited time-to-live
  • 7
    Open Source
  • 6
    Lua scripting
  • 6
    Strings
  • 5
    Awesomeness for Free
  • 5
    Hyperloglogs
  • 4
    Transactions
  • 4
    Outstanding performance
  • 4
    Runs server side LUA
  • 4
    LRU eviction of keys
  • 4
    Feature Rich
  • 4
    Written in ANSI C
  • 4
    Networked
  • 3
    Data structure server
  • 3
    Performance & ease of use
  • 2
    Dont save data if no subscribers are found
  • 2
    Automatic failover
  • 2
    Easy to use
  • 2
    Temporarily kept on disk
  • 2
    Scalable
  • 2
    Existing Laravel Integration
  • 2
    Channels concept
  • 2
    Object [key/value] size each 500 MB
  • 2
    Simple
CONS OF REDIS
  • 15
    Cannot query objects directly
  • 3
    No secondary indexes for non-numeric data types
  • 1
    No WAL

related Redis posts

Russel Werner
Lead Engineer at StackShare · | 32 upvotes · 2.6M views

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

See more
Simon Reymann
Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 9.7M 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
Apache Spark logo

Apache Spark

2.9K
3.5K
140
Fast and general engine for large-scale data processing
2.9K
3.5K
+ 1
140
PROS OF APACHE SPARK
  • 61
    Open-source
  • 48
    Fast and Flexible
  • 8
    One platform for every big data problem
  • 8
    Great for distributed SQL like applications
  • 6
    Easy to install and to use
  • 3
    Works well for most Datascience usecases
  • 2
    Interactive Query
  • 2
    Machine learning libratimery, Streaming in real
  • 2
    In memory Computation
CONS OF APACHE SPARK
  • 4
    Speed

related Apache Spark posts

Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 10.9M views

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

See more
Eric Colson
Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 6.1M views

The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

For more info:

#DataScience #DataStack #Data

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
Memcached logo

Memcached

7.6K
5.5K
473
High-performance, distributed memory object caching system
7.6K
5.5K
+ 1
473
PROS OF MEMCACHED
  • 139
    Fast object cache
  • 129
    High-performance
  • 91
    Stable
  • 65
    Mature
  • 33
    Distributed caching system
  • 11
    Improved response time and throughput
  • 3
    Great for caching HTML
  • 2
    Putta
CONS OF MEMCACHED
  • 2
    Only caches simple types

related Memcached posts

Kir Shatrov
Engineering Lead at Shopify · | 17 upvotes · 1.2M views

At Shopify, over the years, we moved from shards to the concept of "pods". A pod is a fully isolated instance of Shopify with its own datastores like MySQL, Redis, Memcached. A pod can be spawned in any region. This approach has helped us eliminate global outages. As of today, we have more than a hundred pods, and since moving to this architecture we haven't had any major outages that affected all of Shopify. An outage today only affects a single pod or region.

As we grew into hundreds of shards and pods, it became clear that we needed a solution to orchestrate those deployments. Today, we use Docker, Kubernetes, and Google Kubernetes Engine to make it easy to bootstrap resources for new Shopify Pods.

See more
Julien DeFrance
Principal Software Engineer at Tophatter · | 16 upvotes · 3.2M views

Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

Future improvements / technology decisions included:

Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

See more
Apache Ignite logo

Apache Ignite

95
167
41
An open-source distributed database, caching and processing platform
95
167
+ 1
41
PROS OF APACHE IGNITE
  • 5
    Written in java. runs on jvm
  • 5
    Multiple client language support
  • 5
    Free
  • 5
    High Avaliability
  • 4
    Sql query support in cluster wide
  • 4
    Rest interface
  • 4
    Load balancing
  • 3
    Distributed compute
  • 3
    Better Documentation
  • 2
    Easy to use
  • 1
    Distributed Locking
CONS OF APACHE IGNITE
    Be the first to leave a con

    related Apache Ignite posts

    RabbitMQ logo

    RabbitMQ

    21K
    18.5K
    527
    Open source multiprotocol messaging broker
    21K
    18.5K
    + 1
    527
    PROS OF RABBITMQ
    • 234
      It's fast and it works with good metrics/monitoring
    • 79
      Ease of configuration
    • 59
      I like the admin interface
    • 50
      Easy to set-up and start with
    • 21
      Durable
    • 18
      Intuitive work through python
    • 18
      Standard protocols
    • 10
      Written primarily in Erlang
    • 8
      Simply superb
    • 6
      Completeness of messaging patterns
    • 3
      Scales to 1 million messages per second
    • 3
      Reliable
    • 2
      Distributed
    • 2
      Supports MQTT
    • 2
      Better than most traditional queue based message broker
    • 2
      Supports AMQP
    • 1
      Clusterable
    • 1
      Clear documentation with different scripting language
    • 1
      Great ui
    • 1
      Inubit Integration
    • 1
      Better routing system
    • 1
      High performance
    • 1
      Runs on Open Telecom Platform
    • 1
      Delayed messages
    • 1
      Reliability
    • 1
      Open-source
    CONS OF RABBITMQ
    • 9
      Too complicated cluster/HA config and management
    • 6
      Needs Erlang runtime. Need ops good with Erlang runtime
    • 5
      Configuration must be done first, not by your code
    • 4
      Slow

    related RabbitMQ posts

    James Cunningham
    Operations Engineer at Sentry · | 18 upvotes · 1.7M views
    Shared insights
    on
    CeleryCeleryRabbitMQRabbitMQ
    at

    As Sentry runs throughout the day, there are about 50 different offline tasks that we execute—anything from “process this event, pretty please” to “send all of these cool people some emails.” There are some that we execute once a day and some that execute thousands per second.

    Managing this variety requires a reliably high-throughput message-passing technology. We use Celery's RabbitMQ implementation, and we stumbled upon a great feature called Federation that allows us to partition our task queue across any number of RabbitMQ servers and gives us the confidence that, if any single server gets backlogged, others will pitch in and distribute some of the backlogged tasks to their consumers.

    #MessageQueue

    See more

    Around the time of their Series A, Pinterest’s stack included Python and Django, with Tornado and Node.js as web servers. Memcached / Membase and Redis handled caching, with RabbitMQ handling queueing. Nginx, HAproxy and Varnish managed static-delivery and load-balancing, with persistent data storage handled by MySQL.

    See more
    Kafka logo

    Kafka

    23.2K
    21.8K
    607
    Distributed, fault tolerant, high throughput pub-sub messaging system
    23.2K
    21.8K
    + 1
    607
    PROS OF KAFKA
    • 126
      High-throughput
    • 119
      Distributed
    • 92
      Scalable
    • 86
      High-Performance
    • 66
      Durable
    • 38
      Publish-Subscribe
    • 19
      Simple-to-use
    • 18
      Open source
    • 12
      Written in Scala and java. Runs on JVM
    • 9
      Message broker + Streaming system
    • 4
      KSQL
    • 4
      Avro schema integration
    • 4
      Robust
    • 3
      Suport Multiple clients
    • 2
      Extremely good parallelism constructs
    • 2
      Partioned, replayable log
    • 1
      Simple publisher / multi-subscriber model
    • 1
      Fun
    • 1
      Flexible
    CONS OF KAFKA
    • 32
      Non-Java clients are second-class citizens
    • 29
      Needs Zookeeper
    • 9
      Operational difficulties
    • 5
      Terrible Packaging

    related Kafka posts

    Nick Rockwell
    SVP, Engineering at Fastly · | 46 upvotes · 3.5M 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
    Ashish Singh
    Tech Lead, Big Data Platform at Pinterest · | 38 upvotes · 3M views

    To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

    Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

    We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

    Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

    Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

    #BigData #AWS #DataScience #DataEngineering

    See more
    Ehcache logo

    Ehcache

    173
    159
    4
    Java's Most Widely-Used Cache
    173
    159
    + 1
    4
    PROS OF EHCACHE
    • 1
      Way Faster than Redis and Elasticache Redis
    • 1
      Easy setup
    • 1
      Simpler to run in testing environment
    • 1
      Container doesn't have to be running for local tests
    CONS OF EHCACHE
      Be the first to leave a con

      related Ehcache posts