ok.tech: Cassandra meetup
Working with the Apache Cassandra NoSQL repository?
May 23, Classmates invite experienced developers to their office in St. Petersburg for a meeting dedicated to working with Apache Cassandra. What matters is only your experience with Cassandra and the desire to share it.
Register for the event
We at OK started using Apache Cassandra in 2010 to store photo ratings. We are currently the largest users of Apache Cassandra in RuNet and one of the largest in Europe. We have more than a hundred different clusters used both for storing various product information - classes, chats, messages, and for managing critical infrastructure data - mapping logical blocks to large binary storage disks - one-cold-storage , managing internal cloud dataone-cloud etc.
In total, in Odnoklassniki under the control of Cassandra there are petabytes of data on thousands of nodes. During this time, we have accumulated vast experience in the administration, development and operation of solutions based on Cassandra and even developed our own NewSQL transactional database .
Now we would like to share all this with you - on real cases from practice and without secrets; The event will be held in the format of lively discussion between the participants, which means that the discussion will take the bulk of the time. OK experts are ready to share their ideas and approaches. The event will be hosted by Oleg Anastasiev and Alexander Khristoforov .
What are the topics?
Consider typical configurations of nodes and clusters in various production installations. We will discuss how to expand a cluster with an increase in data volumes and load, and how to replace failed nodes with minimal effect for customers. We share the pain and systematize the popular rake. We will figure out how to monitor the cluster in order to understand in advance where and what exactly does not work. We will touch upon the problems of deploying new versions of Cassandra.
Let's try to understand what metrics to look at and what you can tune to make the metrics better. Let’s figure out whether to retrace or not, and if so, how. We identify bottlenecks in the architecture and implementation of Cassandra and consider some engineering tricks to get around them. We touch on sore regular repair and compaction without performance degradation.
Iron does not last forever, so accidents occur all the time, and a colleague’s hand can flinch and we will remove unnecessary, therefore, we will discuss recovery after failures of disks, machines or data centers, as well as rollback to a consistent state from backups in case of operator errors.
Register and tell your friends and colleagues about the event.