OpenSearch ile Elasticsearch Karşılaştırması: Hangisini Seçmeli?

Tarafındankomut
0 Comments

Elastic şirketi 2021 yılında Elasticsearch ve Kibana lisansını Apache 2.0’dan SSPL (Server Side Public License) ve Elastic License kombinasyonuna geçirince, açık kaynak topluluğu ciddi bir sarsıntı yaşadı. AWS de bu gelişme üzerine Elasticsearch 7.10.2 fork’unu alarak OpenSearch projesini başlattı. Bugün bu iki sistem arasında gerçek anlamda ne fark var, hangisini nerede kullanmalısın, birinden diğerine geçiş nasıl yapılır, bunları ayrıntılı inceleyelim.

Lisans ve Yönetim Farkları

Elasticsearch, Elastic License 2.0 (ELv2) altında dağıtılıyor. Bu lisans ticari kullanımda kısıtlamalar getiriyor. Özellikle Elasticsearch’ü kendi ürününüzün bir parçası olarak yeniden dağıtmak istiyorsanız ya da yönetilen servis olarak sunmak istiyorsanız bu lisans size izin vermiyor. Temel sysadmin kullanımı açısından şirket içi kurulumlar için büyük sorun çıkarmıyor ama hukuki belirsizlik orta ve büyük şirketleri tedirgin ediyor.

OpenSearch ise tam anlamıyla Apache License 2.0 altında yayımlanıyor. AWS tarafından başlatılmış olsa da proje şu an bağımsız bir topluluk projesi olarak yönetiliyor, OpenSearch Software Foundation çatısı altında. Red Hat, SAP, eBay gibi büyük oyuncular da projeye katkı sağlıyor. Lisans konusunda tereddütünüz varsa OpenSearch tartışmasız daha güvenli tarafta duruyor.

Temel Mimari ve API Uyumluluğu

OpenSearch, Elasticsearch 7.10.2 baz alınarak fork’landı. Bu yüzden temel API’ler büyük ölçüde aynı. REST API çağrılarınız, index mapping yapılarınız, query DSL’iniz neredeyse birebir çalışıyor. Ancak yıllar geçtikçe iki proje birbirinden ayrışmaya başladı.

Elasticsearch 8.x ile birlikte güvenlik ayarları varsayılan olarak açık geldi, TLS zorunlu hale getirildi ve xpack security artık ücretsiz oldu. OpenSearch’te ise güvenlik plugini zaten başından beri ücretsiz ve varsayılan kurulumda geliyor.

Şu an için Elasticsearch 8.x ile OpenSearch 2.x arasında API uyumsuzlukları var. Özellikle _doc tipinin kaldırılması, mapping type’larının deprecated edilmesi gibi konularda iki sistem farklı yollara gitti.

Kurulum Karşılaştırması

Her iki sistemi de Ubuntu 22.04 üzerinde kuralım, farkları görelim.

Elasticsearch 8.x Kurulumu:

# GPG anahtarı ve repo ekleme
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

sudo apt update && sudo apt install elasticsearch -y

# Kurulum sırasında otomatik üretilen elastic kullanıcı şifresini kaydetmeyi unutmayın
# /etc/elasticsearch/elasticsearch.yml içinde güvenlik varsayılan açık geliyor
sudo systemctl enable elasticsearch --now

OpenSearch 2.x Kurulumu:

# OpenSearch repo ekleme
curl -SL https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/opensearch-2.x.repo | sudo tee /etc/yum.repos.d/opensearch-2.x.repo
# Ubuntu için:
curl -o- https://artifacts.opensearch.org/publickeys/opensearch.pgp | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/opensearch-keyring.gpg] https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-2.x.list

sudo apt update && sudo apt install opensearch -y

# Demo konfigürasyonu ile başlatmak için
sudo /usr/share/opensearch/plugins/opensearch-security/tools/install_demo_configuration.sh -y

sudo systemctl enable opensearch --now

OpenSearch kurulumunda dikkat etmeniz gereken önemli bir nokta var. Security plugini varsayılan geldiğinden ve demo sertifikalar production ortamı için uygun olmadığından, gerçek kurulumda kendi sertifikalarınızı oluşturmanız gerekiyor.

Güvenlik Konfigürasyonu

OpenSearch’ün güvenlik yaklaşımı Elasticsearch’ten farklı. OpenSearch’te tüm güvenlik ayarları opensearch.yml ve özel güvenlik konfigürasyon dosyaları üzerinden yönetiliyor.

# /etc/opensearch/opensearch.yml
plugins.security.ssl.transport.pemcert_filepath: node.pem
plugins.security.ssl.transport.pemkey_filepath: node-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
plugins.security.ssl.transport.enforce_hostname_verification: false
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: node.pem
plugins.security.ssl.http.pemkey_filepath: node-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: root-ca.pem
plugins.security.allow_unsafe_democertificates: false
plugins.security.allow_default_init_securityindex: true
plugins.security.authcz.admin_dn:
  - "CN=admin,OU=ops,O=yourcompany,DC=example,DC=com"

Elasticsearch 8.x’te ise security ayarları farklı:

# /etc/elasticsearch/elasticsearch.yml
xpack.security.enabled: true
xpack.security.enrollment.enabled: true
xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/http.p12
xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12

Elasticsearch’te elasticsearch-reset-password ve elasticsearch-create-enrollment-token gibi araçlar kullanıcı yönetimini kolaylaştırıyor. OpenSearch’te ise securityadmin.sh script’i ile güvenlik konfigürasyonunu uygulamanız gerekiyor.

# OpenSearch security konfigürasyonunu uygulamak
cd /usr/share/opensearch/plugins/opensearch-security/tools/
./securityadmin.sh -cd /etc/opensearch/opensearch-security/ 
  -icl -nhnv 
  -cacert /etc/opensearch/certs/root-ca.pem 
  -cert /etc/opensearch/certs/admin.pem 
  -key /etc/opensearch/certs/admin-key.pem

Performans ve Özellik Karşılaştırması

Iki sistem arasındaki performans farkı genellikle marginal seviyede kalıyor. Benchmark testlerinde benzer workload’lar için %5-10 arasında fark görülüyor, bu fark ortam ve konfigürasyona göre değişiyor. Gerçek dünyada bu fark çoğunlukla hissedilmiyor.

Özellik tarafında ise ayrışma belirginleşiyor:

Elasticsearch’e özgü özellikler:

  • Elastic ML (Machine Learning): Anomali tespiti, NLP modelleri, Eland kütüphanesi
  • EQL (Event Query Language): SIEM senaryoları için geliştirilmiş sorgu dili
  • Kibana Lens: Görsel analiz aracı
  • Elastic Agent ve Fleet: Merkezi agent yönetimi
  • Synthetics Monitoring: Sentetik izleme özellikleri

OpenSearch’e özgü özellikler:

  • OpenSearch Dashboards: Kibana fork’u ama artık bağımsız geliştiriliyor
  • Index State Management (ISM): Rollover, snapshot, delete politikaları için gelişmiş built-in araç
  • Anomaly Detection: ML tabanlı anomali tespiti, temel düzeyde ücretsiz
  • SQL/PPL Support: Pipe Processing Language ile veri sorgulama
  • Cross-Cluster Replication: Ücretsiz geliyor, Elasticsearch’te ücretli plana giriyor
  • Geospatial Features: Gelişmiş coğrafi veri desteği

Cross-cluster replication özelliği OpenSearch kullanan sysadminler için ciddi bir avantaj. Elasticsearch’te bu özellik Platinum lisans gerektiriyordu. Küçük şirketler için bu fark bütçeye doğrudan yansıyor.

Index State Management ile Otomatik Index Yönetimi

OpenSearch’ün öne çıkan özelliklerinden biri ISM (Index State Management). Log yönetimi yapıyorsanız bu özellik çok işe yarıyor.

# OpenSearch ISM policy oluşturma
curl -X PUT "https://localhost:9200/_plugins/_ism/policies/log-rotation-policy" 
  -H "Content-Type: application/json" 
  -u admin:your-password 
  --insecure 
  -d '{
    "policy": {
      "description": "Log index rotation ve silme politikasi",
      "default_state": "hot",
      "states": [
        {
          "name": "hot",
          "actions": [
            {
              "rollover": {
                "min_index_age": "1d",
                "min_size": "5gb"
              }
            }
          ],
          "transitions": [
            {
              "state_name": "warm",
              "conditions": {
                "min_index_age": "2d"
              }
            }
          ]
        },
        {
          "name": "warm",
          "actions": [
            {
              "replica_count": {
                "number_of_replicas": 0
              }
            },
            {
              "force_merge": {
                "max_num_segments": 1
              }
            }
          ],
          "transitions": [
            {
              "state_name": "delete",
              "conditions": {
                "min_index_age": "30d"
              }
            }
          ]
        },
        {
          "name": "delete",
          "actions": [
            {
              "delete": {}
            }
          ],
          "transitions": []
        }
      ]
    }
  }'

Elasticsearch’te benzer işlemi ILM (Index Lifecycle Management) ile yapıyorsunuz ama temel ILM özellikleri Basic lisans ile gelirken warm/cold/frozen tier yönetimi Enterprise seviyede. OpenSearch’te bu kademeli yapıyı tamamen ücretsiz kullanabiliyorsunuz.

Elasticsearch’ten OpenSearch’e Geçiş

Gerçek dünya senaryosu: Elasticsearch 7.x kullanıyorsunuz ve OpenSearch’e geçmek istiyorsunuz. En temiz yol snapshot/restore.

# Adım 1: Elasticsearch tarafında snapshot repository tanımla
curl -X PUT "http://localhost:9200/_snapshot/my_backup" 
  -H "Content-Type: application/json" 
  -d '{
    "type": "fs",
    "settings": {
      "location": "/mnt/backup/elasticsearch",
      "compress": true
    }
  }'

# Adım 2: Snapshot al
curl -X PUT "http://localhost:9200/_snapshot/my_backup/snapshot_migration?wait_for_completion=true" 
  -H "Content-Type: application/json" 
  -d '{
    "indices": "logs-*,metrics-*",
    "ignore_unavailable": true,
    "include_global_state": false
  }'

# Adım 3: OpenSearch tarafında aynı repository'yi tanımla
curl -X PUT "https://localhost:9200/_snapshot/my_backup" 
  -H "Content-Type: application/json" 
  -u admin:your-password 
  --insecure 
  -d '{
    "type": "fs",
    "settings": {
      "location": "/mnt/backup/elasticsearch",
      "compress": true
    }
  }'

# Adım 4: Snapshot'ı restore et
curl -X POST "https://localhost:9200/_snapshot/my_backup/snapshot_migration/_restore" 
  -H "Content-Type: application/json" 
  -u admin:your-password 
  --insecure 
  -d '{
    "indices": "logs-*,metrics-*",
    "ignore_unavailable": true,
    "include_global_state": false,
    "rename_pattern": "(.+)",
    "rename_replacement": "restored_$1"
  }'

Elasticsearch 8.x’ten geçiş yaparken dikkat etmeniz gereken önemli bir nokta var: 8.x snapshot’ları OpenSearch 2.x tarafından direkt olarak restore edilemiyor. Bu durumda önce Elasticsearch 7.10.2 sürümüne downgrade edip snapshot almalı ya da Reindex API veya Logstash üzerinden veri taşıma yapmalısınız.

Monitoring ve Operasyonel Yönetim

Her iki sistemde de cluster sağlığını takip etmek için benzer endpoint’ler kullanılıyor.

# Cluster health kontrolü (her iki sistemde aynı)
curl -X GET "https://localhost:9200/_cluster/health?pretty" 
  -u admin:your-password 
  --insecure

# Node istatistikleri
curl -X GET "https://localhost:9200/_nodes/stats?pretty" 
  -u admin:your-password 
  --insecure | jq '.nodes | to_entries[] | {node: .value.name, heap_used_percent: .value.jvm.mem.heap_used_percent}'

# OpenSearch'e özgü: Index State Management işlem durumu
curl -X GET "https://localhost:9200/_plugins/_ism/explain/logs-*" 
  -u admin:your-password 
  --insecure

OpenSearch Dashboards ve Kibana arasında görsel olarak büyük farklılıklar yok, aynı temelden geldiklerinden dolayı. Ancak OpenSearch Dashboards artık bağımsız yolda ilerliyor ve bazı yeni özellikler Kibana’da yok, tam tersi de geçerli.

Logstash ve Fluentd Entegrasyonu

Veri toplama tarafında her iki sistemle de Logstash ve Fluentd kullanabilirsiniz. OpenSearch için Logstash’te logstash-output-opensearch plugini kullanılıyor.

# Logstash OpenSearch output plugin kurulumu
/usr/share/logstash/bin/logstash-plugin install logstash-output-opensearch
# Logstash konfigürasyonu - OpenSearch output
# /etc/logstash/conf.d/opensearch-output.conf
output {
  opensearch {
    hosts => ["https://opensearch-node1:9200", "https://opensearch-node2:9200"]
    user => "logstash_user"
    password => "logstash_password"
    ssl => true
    ssl_certificate_verification => true
    cacert => "/etc/logstash/certs/root-ca.pem"
    index => "logs-%{+YYYY.MM.dd}"
    action => "index"
    bulk_max_size => 5000
  }
}

Elasticsearch output için mevcut logstash-output-elasticsearch plugini zaten kurulu geliyor, ekstra bir şey yapmanız gerekmiyor. Bu açıdan Elasticsearch biraz avantajlı, ekosistem entegrasyonu daha olgunlaşmış durumda.

Hangisini Seçmeli? Gerçek Dünya Karar Kriterleri

Bu soruya “duruma göre değişir” demek kolay ama biraz daha somutlaştıralım.

OpenSearch tercih etmeli misiniz?

  • Açık kaynak lisans konusunda şirket politikanız katı bir şekilde Apache 2.0 gerektiriyorsa
  • AWS üzerinde Amazon OpenSearch Service kullanıyorsanız ya da kullanmayı planlıyorsanız
  • Cross-cluster replication özelliğine ihtiyaç duyuyorsanız ve bütçeniz kısıtlıysa
  • Log yönetimi odaklı kullanım yapıyorsanız ve ISM ile snapshot management özelliklerini değerlendiriyorsanız
  • On-premise kurulumda security özelliklerini ücretsiz kullanmak istiyorsanız
  • Elasticsearch 7.x’ten taşınıyorsanız ve büyük API değişikliği istemiyorsanız

Elasticsearch tercih etmeli misiniz?

  • Elastic Stack (APM, Uptime, SIEM, Endpoint Security) entegrasyonu istiyorsanız
  • ML tabanlı anomali tespiti ve NLP özellikleri işin özünde yer alıyorsa
  • Elastic Cloud kullanmayı planlıyorsanız
  • Kibana’nın gelişmiş analiz araçlarına (Lens, Canvas) ihtiyaç duyuyorsanız
  • EQL ile SIEM senaryoları kuruyorsanız
  • Elastic’in kurumsal desteği size gerekiyorsa

Küçük ve orta ölçekli operasyonlarda, özellikle log aggregation ve temel arama senaryolarında iki sistem arasındaki fark günlük işlerinizi etkilemiyor. Ama özelliklere özellikle ihtiyaç duyduğunuz noktada hangisinin ücretsiz hangisinin ücretli sunduğu önemli oluyor.

Topluluk ve Ekosistem Durumu

Elasticsearch çok daha büyük ve olgun bir ekosisteme sahip. Stack Overflow’daki soru yoğunluğu, GitHub’daki üçüncü parti kütüphane sayısı, dökümantasyon kalitesi açısından Elasticsearch hala önde. OpenSearch ekosistemi hızla büyüse de bu fark bir süre daha devam edecek.

Ancak OpenSearch tarafında momentum artıyor. Özellikle Kubernetes ortamlarında OpenSearch Operator projesi oldukça aktif geliştiriliyor. Helm chart kalitesi son iki yılda ciddi şekilde ilerledi.

# OpenSearch Kubernetes Operator kurulumu (Helm ile)
helm repo add opensearch-operator https://opensearch-project.github.io/opensearch-k8s-operator/
helm repo update

helm install opensearch-operator opensearch-operator/opensearch-operator 
  --namespace opensearch-operator-system 
  --create-namespace 
  --set manager.image.repository=public.ecr.aws/opensearchproject/opensearch-operator 
  --set manager.image.tag=latest

Sonuç

İki sistem arasında net bir “kazanan” yok. Doğru tercih tamamen kullanım senaryonuza ve kurumsal gereksinimlerinize bağlı.

Eğer 2025 itibarıyla yeni bir proje başlatıyorsanız ve Elastic’in ticari özelliklerine ihtiyaç duymuyorsanız, OpenSearch güvenli ve özgür bir tercih. Lisans belirsizliği yok, çekirdek özellikler ücretsiz, topluluk büyüyor.

Eğer Elasticsearch 7.x veya 8.x üzerinde halihazırda çalışan bir sisteminiz varsa ve sorun yaşamıyorsanız, geçiş için ciddi bir neden olmadan taşıma yapmanın operasyonel riski ve maliyeti çoğunlukla değmiyor.

Sysadmin perspektifinden en kritik nokta şu: İki sistem de production ortamı için olgun ve güvenilir. Hangisini seçerseniz seçin, güvenlik konfigürasyonuna, snapshot stratejinize ve cluster boyutlandırmanıza gereken özeni gösterirseniz sağlıklı bir sistem çalıştırabilirsiniz. Lisans tartışmaları önemli ama operasyonel mükemmellik ondan daha önemli.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir