Image Image Image Image Image Image Image Image Image

Access Keys

July 31, 2013 | By | No Comments">No Comments

SearchBox uses api-keys for authentication to your indices. Api-keys have full control over your account and indices. Many of our users asked us about public api-keys and we are giving you more so-called “access keys”

An access key is a key can be scoped with your indices and aliases with both read-only or full access. This gives you complete tenacity over indices or aliases.

Read-only Access Keys

While creating an access key you can set it as read only and with this key you can “only” execute requests;

  • Search
  • Get
  • MultiGet
  • Get Source

Access Keys With Complete Accees

While creating an access key if you unclick “read only”, created key has now full access to given indices/aliases “except” requests;

  • DeleteIndex
  • CreateIndex
  • All aliases actions

Non-readonly keys can be used for isolating resources without sacrificing index operations, for cases like environments(dev, testqa).

Using Access Keys With Aliases

Indices and aliases handled as same by access keys however this combination has some powerfull outputs.

Aliases can be created with filters. For instance;

If you create an alias to users index named “user_12” with user_id filter, each request made to user_12 will include with that filter.

Now you can create an access-key for this alias and this user will have only access to user_12 alias. With combination of alias filter, that user is completely isolated from other documents, indices and aliases.

Access Keys API

Access keys can be created via dashboard or API

For API details check out documentation

January 2013 Service Interruptions Postmortem

January 3, 2013 | By | No Comments">No Comments

January was kinda nightmare for us due to service interruptions and performance issues. We have resolved most of the issues and made some critical infrastructural changes which led us to make %100 uptime at February.

What was the problem ?

We had several issues, which are;

  • Latency problems
  • Split brain issues
  • GC pressure
  • Cluster time-out problems, some nodes get kicked by master

Some of the issues have best practices to solve, some need more than just configuration. Our cluster was built with m2.medium nodes and cluster was enough in terms of memory and cpu. Even though ElasticSearch just plays very nicely if it scaled horizontally that does not means it will solve all capacity problems. If you don’t have enough memory for each node, JVM starts garbage collections and if garbage collection operations goes very frequently that nodes has potential candidates to be removed from cluster, due to not answering ping requests in time. Also singe core instances suffers these potential issues much more. Another point to consider while scaling horizontally is network latency. Adding more nodes means more network connections also increases latency.

As a conclusion, we have come to;

  • Consider scaling vertically instead of horizontally if you feel safe with availability and search performance (Enough replicas)
  • Network is evil, less communication means low latency and fast responses
  • Singe core cpus does not scale well, more concurrency helps a lot
  • Frequent GCs can harm your cluster, configure discovery time-out values carefully and ensure each individual node has enough memory
  • To avoid split brain issues with discovery.zen.minimum_master_nodes
  • Just adding new nodes may save the day but not tomorrow, monitor your cluster carefully to find out root cause of problems.

So we have changed our cluster from medium instances to m2.large instances, played with configuration to make cluster more stable.

We have %100 uptime and much better latency on February for less money.

You can check out service status here.

Using ElasticSearch With SearchBox on CloudBees

September 27, 2012 | By | No Comments">No Comments

Introduction

Last week we released the first version of Jest which is the missing ElasticSearch Java HTTP rest client. It covers all core API of ElasticSearch and development of rest of the API is in progress.

During this development we got feedback about using SearchBox with CloudBees.

CloudBees provides an end-to-end application environment that lets developers quickly build, deploy, and scale Java web applications using standard Java frameworks and APIs and libraries, written in any JVM language.

After making Jest ready to battle, we wanted to show you how to make it real.

How ?

Jest has a sample Java application and which is ready to rock but to run with CloudBees it needs small modifications.

Jest uses maven and there is a detailed guide how to use maven with CloudBees here.

Here step by step guide.

  • First clone Jest;
  • Then go to pom.xml and;

Add CloudBees plugin repository after “dependencies”;

Add CloudBees plugin inside “plugins”;

  • You should have 2 things to go further, SearchBox and CloudBees accounts.

Assuming you have got both which are an api-key from SearchBox and an application-id from CloudBees.

  • Find SpringConfiguration.java and change line starts with servers.add(…) with below Java code; (Don’t forget to change “YOUR-API-KEY” with your SearchBox.io api-key.)

All is set, we just need to deploy our application to CloudBees.

  • Change “YOUR-APP-ID” with your CloudBees “application id” and execute it.

You should see an output like something below.

  • Now open your browser and visit you application. You will see “Create Articles”, click it, 2 sample articles will be indexed.
  • Type “Lord” to search box on top right and hit enter, you have a result? Awesome!

As you see, it is very easy to combine powers of SearchBox and CloudBees, I hope you enjoyed it.

Happy coding.