Yum Install ElasticSearch 1.x

Note: Works for CentOS/RHEL/Fedora.

rpm --import http://packages.elasticsearch.org/GPG-KEY-elasticsearch

vim /etc/yum.repos.d/elasticsearch.repo

[elasticsearch-1.0]
name=Elasticsearch repository for 1.0.x packages
baseurl=http://packages.elasticsearch.org/elasticsearch/1.0/centos
gpgcheck=1
gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
enabled=1

yum update
yum install java-1.7.0-openjdk.i686 -y
yum install elasticsearch

Start ElasticSearch

/etc/init.d/elasticsearch start

If you are wondering where the data directory is for this installations steps, it is stored at:

/var/lib/elasticsearch/elasticsearch

RPM Install ElasticSearch on Linux

It's as simple as,

rpm -ivH https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.1.noarch.rpm

For other versions,

rpm -ivH https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-<VERSION NUMBER>.noarch.rpm

Replace <VERSION NUMBER> with the version of elasticsearch you want installed.

This installation process works on CentOS/RHEL 5.x-6.x, Fedora 16 up (with internet). Dependency was not checked, so be warned.  Might work on other Linux systems that use RPM.

System Performance Optimization Basics on the Resource Level

Before moving on to optimizing your application, take a look first at infrastructure or resource level whether the problem lies in there. There are four areas that directly attribute to your system performance at the resource level. You should derived your optimizations based on them.

CPU (Central Processing Unit)

Processor speed dictates how many instructions per second can you execute per second which is measured as cycles/second or hertz (i.e 2.3 Ghz). The bigger the number the better the performance. But 1 processor can be used 1 at a time only. There is no such this as percent usage. The CPU utilization percentage you usually see only indicate how long a process was seen at a given time period. Now, parallel processing is common and multi-core CPUs are available. The number of processor cores gives you the number of processes that can be run at the same time. This can be fully utilized if your system uses multi-processing and multi-threading paradigms.

MongoDb 1.6 Released - Scaling Production Ready At Last!!!

With the release of the MongoDB version 1.6 Stable, which focuses in scaling, this rockin' DBMS just made sharding and replica sets production ready.

What does it mean?

It means that you can now rely on Mongodb to:

1. Shard when the need arises.
2. Add servers to your cluster at zero downtime.
3. Single point-of-failure is no longer a problem making your systems highly available.
4. Replication lag, reduced dramatically if not totally.

Introduction to Service-Oriented Architecture

Service-Oriented Architecture have been a discussion even as early as late 90s. This system architecture is meant to expose macro-level services that can be consumed by business directly instead of the micro-level software components like classes. It also encompasses abilities of being able to distribute and aggregate services from different topographical locations through the internet. Imagine a system similar to previous software architectures and technologies like modular programming, component-based design, object-oriented programming etc, except that it can be distributed across different technologies, platforms, network and location given that they should have common interfaces promoting interoperability.