ScyllaDB Deployment Best Practices: General Useful Advice

So let’s start by talking about your first and like when
you’re just getting started. One of the things that we take very seriously is
compatibility. Initially with Cassandra and now as you were seeing we are adding
more APIs, we’re adding more to that so one of the ideas that you shouldn’t have
to learn that stuff but that is a double-edged sword
Things to remember when you come from other databases. Data model is the same
so how I summarized this is that remember what you learn from Cassandra
if you’re coming from Cassandra about data model but whatever you know about
operations, just think through it again.. Because what we see a lot of times is
people doing things in Cassandra not because that’s the best thing to do but
just because you had to do this to work around the problem or like you had to
put a cache here, because the read performance wasn’t great or you didn’t
compact your data often enough, because it would take as I heard from a customer
once, are you asking me to do in their use case like a major compaction every
day, how am I supposed to do something daily that takes three days to run?
So I’ll try it and took two hours so yeah something that takes two hours you can
do daily.. So in general like data model is
something that it’s going to be about the same
but try to reevaluate if you have an operational procedure even though the
way you do it is the same I mean should. I still do this procedure and obviously
we’re there to help you if you need any guidance with that. A corollary of this
is how you compare those database so if this is like even before you start if
you’re doing a comparison yeah certainly you can try to do a comparison like
using exactly the same hardware, exactly the same data model everything
exactly and that does tell you something that is good information I’m
not going to say you should never do that but there’s
also the fact that those different databases will perform differently in
different scenarios they’re gonna have their strengths and weaknesses, so the
way I like to approach this problem better is like, here is my problem and if
at all possible let me take a step back and try to reevaluate. Am I
doing the things, playing to the strengths of those databases instead of
just doing it because I was doing it before. Some general useful advice. This
is for everybody like monitor your clusters. We hear this all the time like
I’m having an issue and then you describe the issue to me and you expect
an answer like what could go wrong and my first question is always like are you
monitoring your cluster? The answer is no.. Please start doing this and sometimes
you don’t even need my help anymore because we invest a lot of time and
effort into making sure that the ScyllaDB monitor has a lot of information that
this information is readily available and it’s easy to consume a lot of your
bottlenecks a lot of the things that what could my bottleneck be just by
looking at the graphs you’re gonna be able to see so running your cluster
without monitoring is the the most sure way to fail, just don’t do it. Also, try to
keep your versions up-to-date, do upgrades often and we understand and
realize that mean we don’t necessarily want you upgrade often, there is such a
thing as like maybe I want to be conservative I am okay with that so
there are situations in which you want to move faster there are situations in
which you want to move slower but if you move too slow and you get too far behind
at that point you are in a version that is no longer
supported. So if there is a problem and problems every time every now and then
they do pop up, you’re not gonna get a patch for that so our policy is usually
two versions so if you are an open source that’s 3.0 right now it’s 3.1 and
3.0 that means if you are in 2.3 you are on an unsupported version and enterprise
versions follow the same exactly the same idea there cycles are much longer
so you’re gonna have to upgrade less often but do upgrade so for instance if
you are using ScyllaDB Enterprise 2017 you’re not actually in the supported
version if you do have a problem you’re not gonna have a patch, running the
previous version is okay as I said is a conservative thing to do you allow other
people who have a higher risk tolerance to find the issues first but don’t
run too old and try to keep the patch levels up to date. The patch levels are,
we also put a lot of effort into making sure that they are very low risk so if
you’re using 3.1 we just released for example 3.1.1
Try to be always in the latest patch level.