3CX’teki Çağrı Veri Kayıtları (CDR) Sisteminde büyük yükseltme.

Dünkü V20 Update 6 Alpha sürümünün ardından, bu gönderi 3CX’teki yeni Çağrı Veri Kayıtları (CDR) sistemini açıklıyor; burada CDR’yi tek bir tabloya dönüştürdük: cdr_output. Eski yapıyı parçalara ayırıyoruz, yeni tasarımı ortaya koyuyoruz ve çağrı verilerinin nasıl çalıştığını dönüştüren teknik kazanımları vurguluyoruz. Tüm ayrıntılar için okumaya devam edin.

Eski Kurulum: Parçalanmış Bir Darboğaz

Başlangıçta, 3CX’in CDR / çağrı verileri dört tabloya bölünmüştü: cl_calls, cl_participants, cl_party_info, ve cl_segments. Her biri çağrı yaşam döngüsünün farklı öğelerini depoladı: zaman damgaları, katılımcı verileri ve yönlendirme ayrıntıları – karmaşık SQL JOIN’lerin tam bir kaydı bir araya getirmesini zorunlu kılıyordu. Bu çok tablolu tasarım sorgu yükünü artırdı ve rapor oluşturma performansını yavaşlattı. Bulut ölçeğinde analiz veya gerçek zamanlı raporlama için yapı basitçe ayak uyduramadı.

Yeni Yaklaşım: cdr_output

Bunu, tüm çağrı verilerini tek bir verimli tabloda birleştiren tek tablolu bir çözüm olan cdr_output olarak dönüştürdük. Zaman damgaları, katılımcılar, yönlendirme ve sonuçlar – her şey birleştirildi ve JOIN’lere olan ihtiyaç ortadan kalktı. JOIN yalnızca kendi tablosunda cdr_recordingsout bulunan Kayıt Verileri için gereklidir. 3CX’te her zaman binlerce kullanıcıya ölçeklenebildik. Bu yalın mimari ölçeklenebilirliğimizi daha da güçlendiriyor, karmaşıklığı azaltıyor, sorgu hızını artırıyor ve 3CX’i buluta hazır analizler için hazır hale getiriyor. Bu, hassasiyet ve güç sunmak için oluşturulmuş, veri mühendisliğinin cesur bir yeniden düşünülmesidir.

İlerleme #1: Tüm Verileriniz Tek Bir Akıllı Tabloda

Eski: Çok tablolu JOIN’ler performansı kısıtladı; çağrı içgörülerini incelemek için gerçek bir baş ağrısı.
Yeni: cdr_output her şeyi – kaynak, hedef, zaman damgaları, sonuçlar – tek bir kompakt tabloya yerleştiriyor. Düz ve basit, ilişkisel karmaşayı ortadan kaldırıyor, böylece BI analistleri çağrı akışlarını kolayca takip edebiliyor.

Neden Harika:

  • Daha Hızlı Sorgular: Çok tablolu karmaşıklığı tek tablolu hız için terk eder – sorgular veri boyutu ne olursa olsun sorunsuz bir şekilde ölçeklenir.
  • Buluta Hazır: Doğrudan veri göllerine veya BI araçlarına kayar – ekstra hazırlık gerekmez.
  • Analist Kazancı: Arama yolları açıktır ve izlenmesi hızlıdır, saatlerce uğraştan kurtulursunuz.

Teknoloji Üstünlüğü: cdr_id ve call_history_id üzerindeki dizinler, devasa veri kümeleriyle bile yıldırım hızında aramalar için PostgreSQL’i hızlandırır. call_history_id bağlantılarını tablo içinde tutmak SQL yükünü azaltır, hızı artırır ve veri şişkinliğini azaltır.

İlerleme #2: Her Sıra Hikayeyi Anlatır

Eski: İnce veri rapor analistlerini tahmin etmeye zorladı – bir çağrı neden başarısız oldu? Bağlam nerede? Kim kime transfer etti?
Yeni: cdr_output zengin bir öznitelik kümesini gömer:

  • termination_reason (örnek, “cancelled”, “dst_participant_terminated”)
  • termination_reason_details (örnek, “forward_all”, “completed_elsewhere”)
  • creation_method (örnek, “route_to”, “divert”)
  • creation_forward_reason (örnek, “polling”, “busy”)
  • continuation_reason (örnek, “polling”, “forward_all”)

Etki:

  • Toplam Netlik: Her satır tam bir hikayedir – artık ipuçlarını bir araya getirmeye gerek yok.
  • Daha Akıllı İçgörüler: Düşme oranları veya kuyruk istatistikleri gibi KPI’ları güçlendirir, ekstra çalışma gerektirmez.
  • Son Oyun Açıklaması: Bir aramayı nasıl, neden, ne zaman ve kimin sonlandırdığını anında görün

Teknoloji Üstünlüğü: termination_reason_details, kesin analizleri destekler (Grafana veya PowerBi’den SQL GROUP BY düşünün) ve UUID tabanlı cdr_id artık BI araçlarının tarih-saat ve çağrı sırasını kutudan çıktığı gibi belirlemesine olanak tanıyan 00000000-01db-87c1-1bab-07aa0000000d GUID standardıdır. Her şey oradadır – bir çağrının nasıl başladığı, hareket ettiği ve bittiği.

İlerleme #3: Kim Kimi Arıyor, Basitleştirildi

Eski: Katılımcı rolleri yetersiz tanımlanmıştı – kaynak ve hedef çapraz tablo çıkarımı, tahmin, iç içe geçmiş işlemler, Çoklu JOIN ve performans canavarları gerektiriyordu.
Yeni: cdr_output, bir dizi temiz bölünmüş özellik ile önceki SQL JOIN karmaşalarını evcilleştiriyor:

  • source_participant_id (takip için kullanılır)
  • source_participant_phone_number (örneğin, “+1305305305”)
  • destination_dn_name (örneğin, “Dana White”)
  • source_participant_is_incoming ve destination_participant_is_already_connected gibi işretler
Kaynak Yeni Özellikler Katılımcı Yeni Özellikler
“source_participant_id” “destination_participant_id”
“source_entity_type” “destination_entity_type”
“source_dn_number” “destination_dn_number”
“source_dn_type” “destination_dn_type”
“source_dn_name” “destination_dn_name”
“source_participant_name” “destination_participant_name”
“source_participant_phone_number” “destination_participant_phone_number”
“source_participant_trunk_did” “destination_participant_trunk_did”
“source_participant_is_incoming” “destination_participant_is_incoming”
“source_participant_is_already_connected” “destination_participant_is_already_connected”

Etki:

  • Hassas Eşleme: Çağrı yönü açıktır – kaynaktan hedefe, tamamlandı, akış analizini kolaylaştırır.
  • Karmaşık Senaryolar Ele Alınır: Tek bir şemada birden fazla kuyruk akışını, çift yönlü hatları ve çok katmanlı transferleri sorunsuz bir şekilde izler.

Teknoloji Üstünlüğü: Boolean durum bayrakları bir veri ambarının boyutsal modellemesini yansıtır ve WHERE ifadesinin performansını optimize eder. Katılımcı kimliklerindeki UUID standardı, BI platformlarıyla sorunsuz entegrasyonu garanti eder ve çağrı ayağı sıralamasını kutudan çıktığı haliyle korur.

İlerleme #4: Zaman Damgası Ayrıntı Düzeyi

Eski: cl_calls temel başlangıç/bitiş saatleri sunuyordu; cl_segments geri kalanını parçalara ayırdı.
Yeni: cdr_output üç kesin zaman damgası sunuyor: cdr_started_at, cdr_ended_at, cdr_answered_at.

Etki:

  • Keskin Ölçümler: Kesin çalma-cevap sürelerini yakalar – her saniye önemlidir.
  • Analitik Basitlik: Tek tablolu hesaplamalar, çok tablolu toplamaların yerini alır.

Uzman Görüşü: UTC zaman damgaları (+00) bölgeler arasında tutarlılığı garanti eder; Snowflake veya BigQuery gibi araçlara beslenen küresel bulut dağıtımları için olmazsa olmazdır. GUID tabanlı cdr_id, bu zaman damgalarını çağrı bacaklarına bağlayarak BI araçlarına sıra ve süre konusunda yerel bir anlayış kazandırır. Ayarlamaya gerek yoktur.

İlerleme #5: Büyüme İçin Tasarlandı

Eski: Çoklu tablolu kurulumlar katıydı – yeni özellikler şemanın tamamen yayılması anlamına geliyordu.
Yeni: cdr_output tek, genişletilebilir bir tablodur – bir sütun ekleyin ve sistem uyum sağlar.

Etki:

  • Geleceğe Hazır Ölçek: İlişkisel ek yük olmadan 3CX’in yol haritasıyla büyür.
  • Operasyonel Verimlilik: Dizin oluşturmak, çoğaltmak veya bölümlemek için tek bir tablo – tasarım gereği buluta özgü olacak şekilde oluşturulmuştur.

Uzman Görüşü: processed ve migrated gibi bayraklar veri hatlarını düzene sokarak Apache Kafka, AWS Athena veya Kinesis ve Google BigQuery ile sorunsuz entegrasyon sağlar. Tablo içindeki call_history_id bağlantısı ilgili çağrı sorgularını hızlandırır, performansı sıkı ve veri yüklerini yalın tutar.

Sonraki Adım – Bulut Verilerini Hazırlamak

Hantal bir CDR sistemini modern, ölçeklenebilir bir çağrı raporlama tablosuna dönüştürdük. Ölçütlerimiz sorguların 10 kata kadar daha hızlı olduğunu gösteriyor – daha az JOIN, daha zengin veriler. İyi Raporlamalar!

Update 6 Alpha ile Başlayın

Bu yeni özellikleri denemek için V20 Update 6 Alpha’ya yükseltin.

Özel Ortak veya Müşteri Forumlarımızda V20 tartışmalarına katılın. En son haberle ve özellik sürümleri hakkında güncel kalmak için bizi X ve LinkedIn’de takip edin.