First Turkish translation contribution of ClickHouse! (#10297)

* Manual translation to TR

First Turkish translation contribution of ClickHouse!

* Update index.md
Co-authored-by: NIvan Blinkov <github@blinkov.ru>

docs/tr/index.md

 ---
-machine_translated: true
-machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
 toc_priority: 0
 toc_title: "Genel bak\u0131\u015F"
 ---
 
 # ClickHouse nedir? {#what-is-clickhouse}
 
-ClickHouse, sorguların çevrimiçi analitik işlenmesi (OLAP) için sütun odaklı bir veritabanı yönetim sistemidir (DBMS).
+ClickHouse, sorguların çevrimiçi analitik işlenmesi (*Online Analytical Processing* - OLAP) için sütun odaklı bir Veritabanı Yönetim Sistemidir (*DataBase Management System* - DBMS).
 
-İn a “normal” satır yönelimli DBMS, veri bu sırayla saklanır:
+“Normal” bir satır odaklı DBMS içinde veriler şu şekilde saklanır:
 
-| Satır | Watchıd     | JavaEnable | Başlık               | GoodEvent | EventTime           |
+| Satır | WatchId     | JavaEnable | Başlık               | İyiOlay | OlayZamanı           |
 |-------|-------------|------------|----------------------|-----------|---------------------|
 | \#0   | 89354350662 | 1          | Yatırımcı İlişkileri | 1         | 2016-05-18 05:19:20 |
 | \#1   | 90329509958 | 0          | Bize ulaşın          | 1         | 2016-05-18 08:10:20 |
@@ -20,47 +18,47 @@ ClickHouse, sorguların çevrimiçi analitik işlenmesi (OLAP) için sütun odak
 
 Başka bir deyişle, bir satırla ilgili tüm değerler fiziksel olarak yan yana depolanır.
 
-Satır yönelimli DBMS örnekleri MySQL, Postgres ve MS SQL Server'dır.
+MySQL, Postgres ve MS SQL Server gibi veritabanları satır odaklı DBMS örnekleridir.
 
-Sütun yönelimli bir DBMS'DE, veriler şu şekilde saklanır:
+Sütun odaklı bir DBMS'de ise veriler şu şekilde saklanır:
 
 | Satır:      | \#0                  | \#1                 | \#2                 | \#N |
 |-------------|----------------------|---------------------|---------------------|-----|
-| Watchıd:    | 89354350662          | 90329509958         | 89953706054         | …   |
+| WatchId:    | 89354350662          | 90329509958         | 89953706054         | …   |
 | JavaEnable: | 1                    | 0                   | 1                   | …   |
 | Başlık:     | Yatırımcı İlişkileri | Bize ulaşın         | Görev               | …   |
-| GoodEvent:  | 1                    | 1                   | 1                   | …   |
-| EventTime:  | 2016-05-18 05:19:20  | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | …   |
+| İyiOlay:  | 1                    | 1                   | 1                   | …   |
+| OlayZamanı:  | 2016-05-18 05:19:20  | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | …   |
 
 Bu örnekler yalnızca verilerin düzenlendiği sırayı gösterir. Farklı sütunlardaki değerler ayrı olarak depolanır ve aynı sütundaki veriler birlikte depolanır.
 
-Bir sütun odaklı DBMS örnekleri: Vertica, Paraccel (Actian Matrix ve Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise ve Actian vektör), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid ve kdb+.
+Sütun odaklı DBMS örnekleri: Vertica, Paraccel (Actian Matrix ve Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise ve Actian vektör), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid ve kdb+.
 
-Different orders for storing data are better suited to different scenarios. The data access scenario refers to what queries are made, how often, and in what proportion; how much data is read for each type of query – rows, columns, and bytes; the relationship between reading and updating data; the working size of the data and how locally it is used; whether transactions are used, and how isolated they are; requirements for data replication and logical integrity; requirements for latency and throughput for each type of query, and so on.
+Verinin farklı bir şekilde sıralanarak depolanması, bazı veri erişim senaryoları için daha uygundur. Veri erişim senaryosu, hangi sorguların ne kadar sıklıkla yapıldığını, ne kadar verinin okunduğu, bunların hangi tiplerde hangi kolonlardan, satırlardan ve hangi miktarda(bayt olarak) okunacağını; verinin okunması ile güncellenmesi arasındaki ilişkiyi; verinin işlenen boyutu ve ne kadar yerel olduğunu; veri değiş-tokuşunun(transaction) olup olmayacağını, olacaksa diğer işlemlerden ne kadat yalıtılacağını; verilerin kopyalanması ve mantıksal bütünlük intiyaçlarını; her sorgu türünün gecikme ve iletim debisi ihtiyaçlarını gösterir.
 
-Sistem üzerindeki yük ne kadar yüksek olursa, kullanım senaryosunun gereksinimlerine uyacak şekilde ayarlanmış sistemi özelleştirmek o kadar önemlidir ve bu özelleştirme o kadar ince taneli olur. Önemli ölçüde farklı senaryolara eşit derecede uygun bir sistem yoktur. Bir sistem geniş bir senaryo kümesine uyarlanabilirse, yüksek bir yük altında, sistem tüm senaryoları eşit derecede zayıf bir şekilde ele alır veya olası senaryolardan yalnızca biri veya birkaçı için iyi çalışır.
+Sistem üzerindeki yük ne kadar fazlaysa, sistem ayarlarının kullanım senaryolarına uyarlanması ve bu ayarların ne kadar hassas olduğu da o kadar önemli hale gelir. Birbirinden büyük ölçüde farklı olan veri erişim senaryolarına tam uyum sağlayan, yani her işe ve yüke gelen bir sistem yoktur. Eğer bir sistem yük altında her türlü veri erişim senaryosuna adapte olabiliyorsa, o halde böyle bir sistem ya tüm senaryolara ya da senaryoların bir veya birkaçına karşı zayıp bir performans gösterir.
 
 ## OLAP senaryosunun temel özellikleri {#key-properties-of-olap-scenario}
 
--   İsteklerin büyük çoğunluğu okuma erişimi içindir.
+-   İsteklerin büyük çoğunluğu, okuma erişimi içindir.
 -   Veriler, tek satırlarla değil, oldukça büyük gruplar halinde (\> 1000 satır) güncellenir; veya hiç güncellenmez.
--   Veri DB eklenir, ancak değiştirilmez.
--   Okumalar için, dB'den oldukça fazla sayıda satır çıkarılır,ancak yalnızca küçük bir sütun alt kümesi.
--   Tablolar şunlardır “wide,” çok sayıda sütun içerdikleri anlamına gelir.
--   Sorgular nispeten nadirdir (genellikle sunucu başına yüzlerce sorgu veya saniyede daha az).
+-   Veri, veritabanına eklenir, ancak değiştirilmez.
+-   Bazı sorgular için veritabanından den oldukça fazla sayıda satır çekilir, ancak sonuç sadece birkaç satır ve sütunludur.
+-   Tablolar "geniştir", yani bir tabloda çok sayıda kolon vardır(onlarca).
+-   Sorgular sıkılığı diğer senaryolara göre daha azdır (genellikle sunucu başına saniyede 100 veya daha az sorgu gelir).
 -   Basit sorgular için, 50 ms civarında gecikmelere izin verilir.
--   Sütun değerleri oldukça küçüktür: sayılar ve kısa dizeler (örneğin, URL başına 60 bayt).
--   Tek bir sorguyu işlerken yüksek verim gerektirir (sunucu başına saniyede milyarlarca satıra kadar).
--   İşlemler gerekli değildir.
--   Veri tutarlılığı için düşük gereksinimler.
--   Sorgu başına bir büyük tablo var. Biri hariç tüm tablolar küçüktür.
--   Bir sorgu sonucu, kaynak veriden önemli ölçüde daha küçüktür. Başka bir deyişle, veriler filtrelenir veya toplanır, böylece sonuç tek bir sunucunun RAM'İNE sığar.
+-   Saklanan veriler oldukça küçüktür: genelde sadece sayılar ve kısa metinler içerir(örneğin, URL başına 60 bayt).
+-   Tek bir sorguyu işlemek yüksek miktarda veri okunmasını gerektirir(sunucu başına saniyede milyarlarca satıra kadar).
+-   Veri değiş-tokuşu(transaction) gerekli değildir.
+-   Veri tutarlılığı o kadar da önemli değildir.
+-   Genelde bir tane çok büyük tablo vardır, gerisi küçük tablolardan oluşur
+-   Bir sorgu sonucu elde edilen veri, okuanan veri miktarından oldukça küçüktür. Başka bir deyişle, milyarlarca satır içinden veriler süzgeçlenerek veya birleştirilerek elde edilen verilerin tek bir sunucunun RAM'ine sığar.
 
-OLAP senaryosunun diğer popüler senaryolardan (OLTP veya anahtar değeri erişimi gibi) çok farklı olduğunu görmek kolaydır. Bu nedenle, iyi bir performans elde etmek istiyorsanız, analitik sorguları işlemek için OLTP veya anahtar değeri DB'Yİ kullanmayı denemek mantıklı değildir. Örneğin, analitik için MongoDB veya Redis kullanmaya çalışırsanız, OLAP veritabanlarına kıyasla çok düşük performans elde edersiniz.
+OLAP senaryosunun diğer popüler senaryolardan (*Online Transactional Processing* - OLTP veya *Key-Value* veritabanı) çok farklı olduğu açıkça görülebilir. Bu nedenle, iyi bir performans elde etmek istiyorsanız, analitik sorguları işlemek için OLTP veya *Key-Value* veritabanlarını kullanmak pek mantıklı olmaz. Örneğin, analitik için MongoDB veya Redis kullanmaya çalışırsanız, OLAP veritabanlarına kıyasla çok düşük performans elde edersiniz.
 
 ## Sütun yönelimli veritabanları OLAP senaryosunda neden daha iyi çalışır {#why-column-oriented-databases-work-better-in-the-olap-scenario}
 
-Sütun yönelimli veritabanları OLAP senaryolarına daha uygundur: çoğu sorgunun işlenmesinde en az 100 kat daha hızlıdır. Nedenleri aşağıda ayrıntılı olarak açıklanmıştır, ancak gerçek görsel olarak göstermek daha kolaydır:
+Sütun yönelimli veritabanları OLAP senaryolarına daha uygundur: hatta o kadar ki, çoğu sorgunun işlenmesi en az 100 kat daha hızlıdır. Her ne kadar OLAP veritabanlarının neden bu kadar hızlı olduğuna dair nedenler aşağıda ayrıntılı verilmiş olsa da görseller üzerinden anlatmak daha kolay olacakttır:
 
 **Satır yönelimli DBMS**
 
@@ -70,7 +68,7 @@ Sütun yönelimli veritabanları OLAP senaryolarına daha uygundur: çoğu sorgu
 
 ![Column-oriented](images/column_oriented.gif#)
 
-Farkı görüyor musun?
+Farkı görüyor musunuz?
 
 ### Giriş/çıkış {#inputoutput}