Out of the box, Kibana includes the ability to display geo-data on maps provided by Elastic's tile service. This provides a great introduction to what Kibana can do, but the maximum zoom level is limited if you don't have an X-Pack license. For example, the maximum zoom for ObjectRocket's home base of Austin, Texas is below

The MongoDB command line utility, rs.remove(), is used to remove a member from a replica set. Prior to MongoDB version 3.0, the rs.remove() command would cause elections to occur. However, starting with version 3.0 this is no longer the case. From version 3.0 onwards, the rs.remove operation will not cause any elections. This is good news for several reasons.

Databases aren’t easy to manage. They occupy a lot of hardware, require valuable man-hours to maintain, and there aren’t that many people qualified to work on them if something goes very wrong. Plus, they are a mystery to most business units outside of IT. That doesn’t mean that databases aren’t an absolute necessity, though. They are. The datastore has always been a key component of any application. Now that businesses have shifted toward “big data,” people want access to even more information than ever before, which means more new databases. It’s become absolutely crucial for businesses to harness “big data” to make informed decisions about customers and their needs based on data analysis.

Database Administrators (DBAs) used to be the masters of their domain. They were the intermediary that stood between the databases necessary to conduct daily business and rest of the company. Not only were they the gatekeepers responsible for protecting the data but also the schemas that held that data. They were responsible for running the whole system, top to bottom, performing any task required to keep the database servers functional.

We hear it a lot. One of the most painful aspects of database maintenance are the upgrades. It can be scary to upgrade to the latest version of Elasticsearch or any datastore. The Elastic Stack is updated more regularly than most datastores and each release brings major new features, bug fixes, or enhancements. When evaluating an upgrade to a newer version, you may have some features you’d like to add and there may be some nagging bugs you’d like to squash. Other than that, your app is working and you don’t want to mess with a good thing and decide to stay on the version that’s working. So, you get farther behind and it becomes even harder to move on to the latest version. We talk to many businesses that find themselves in this situation; they use early versions of Elasticsearch and they’ve gotten really far behind. They feel stuck.

A question faced by a lot of companies as they start out (especially tech-based companies) is whether they want to outsource certain functions or do them in-house. Making this decision can sometimes be difficult, since it can seem expensive whether you’re hiring your own crew or paying another company to get it done.

Today we're announcing that Elasticsearch 6.0.0 is now available on the ObjectRocket service. Though this is not as big a launch as last year's release of Elasticsearch 5.0, there are still a number of major additions and improvements you can take advantage of in the new version. You can try it out now, in the the ObjectRocket app.

Some of the most common sources of support tickets we see on the ObjectRocket for Elasticsearch platform are related to indexing, shard count, and replication decisions. Elasticsearch is awesome at spreading data across your cluster with the default settings, but once your cluster begins to grow, the defaults can get you in trouble. Let’s go over some of the basics of sharding and provide some best practices for indexing and shard count.