Zaman serisi verileri, modern uygulamalar\u0131n ve sistemlerin ayr\u0131lmaz bir par\u00e7as\u0131 haline geldi. Sens\u00f6rlerden gelen telemetri verileri, finansal piyasa hareketleri, uygulama performans metrikleri gibi s\u00fcrekli artan veri ak\u0131\u015flar\u0131, depolama ve y\u00f6netim a\u00e7\u0131s\u0131ndan ciddi zorluklar yaratmaktad\u0131r. TimescaleDB, PostgreSQL tabanl\u0131, zaman serisi verileri i\u00e7in optimize edilmi\u015f g\u00fc\u00e7l\u00fc bir \u00e7\u00f6z\u00fcm sunsa da, veri hacminin kontrol alt\u0131nda tutulmas\u0131 kritik \u00f6neme sahiptir. Bu makalede, TimescaleDB’nin geli\u015fmi\u015f s\u0131k\u0131\u015ft\u0131rma \u00f6zelliklerini kullanarak, ger\u00e7ek bir \u00fcretim ortam\u0131nda 150GB’l\u0131k bir veri setini nas\u0131l 15GB’a d\u00fc\u015f\u00fcrd\u00fc\u011f\u00fcm\u00fcz\u00fc, yani %90’l\u0131k \u015fa\u015f\u0131rt\u0131c\u0131 bir azalma elde etti\u011fimizi detayl\u0131 bir \u015fekilde inceleyece\u011fiz.<\/p>\n
Zaman serisi verileri, do\u011fas\u0131 gere\u011fi s\u00fcrekli b\u00fcy\u00fcyen, genellikle ekleme a\u011f\u0131rl\u0131kl\u0131 (append-only) ve y\u00fcksek hacimli verilerdir. Bu durum, zamanla depolama maliyetlerinin artmas\u0131na, yedekleme s\u00fcrelerinin uzamas\u0131na ve sorgu performans\u0131n\u0131n d\u00fc\u015fmesine neden olabilir. TimescaleDB, bu zorluklara kar\u015f\u0131 PostgreSQL’in g\u00fcvenilirli\u011fini ve esnekli\u011fini zaman serisi yetenekleriyle birle\u015ftirerek g\u00fc\u00e7l\u00fc bir \u00e7\u00f6z\u00fcm sunar.<\/p>\n
Zaman serisi verileri genellikle bir zaman damgas\u0131, bir cihaz veya sens\u00f6r kimli\u011fi ve \u00f6l\u00e7\u00fclen bir de\u011ferden olu\u015fur. Bu veriler saniyede y\u00fczlerce, hatta binlerce kay\u0131t \u015feklinde akabilir. \u00d6rne\u011fin, bir IoT cihaz\u0131 her saniye s\u0131cakl\u0131k, nem ve bas\u0131n\u00e7 gibi de\u011ferleri g\u00f6nderdi\u011finde, bu veriler h\u0131zla birikerek devasa boyutlara ula\u015fabilir. Bu s\u00fcrekli ak\u0131\u015f, geleneksel ili\u015fkisel veritabanlar\u0131 i\u00e7in \u00f6l\u00e7eklenebilirlik sorunlar\u0131 yaratabilir.<\/p>\n
B\u00fcy\u00fck veri setleri, sadece disk alan\u0131 maliyetini art\u0131rmakla kalmaz, ayn\u0131 zamanda veritaban\u0131 operasyonlar\u0131n\u0131 da yava\u015flat\u0131r. Yedekleme ve geri y\u00fckleme i\u015flemleri saatler s\u00fcrebilir, indekslerin boyutu b\u00fcy\u00fcd\u00fck\u00e7e sorgu performans\u0131 d\u00fc\u015febilir ve sunucu kaynaklar\u0131 (CPU, RAM) \u00fczerindeki y\u00fck artar. \u00d6zellikle uzun s\u00fcreli veri saklama politikalar\u0131 olan sistemlerde, bu zorluklar s\u00fcrd\u00fcr\u00fclebilirli\u011fi tehdit edebilir.<\/p>\n
TimescaleDB, PostgreSQL’in g\u00fc\u00e7l\u00fc altyap\u0131s\u0131n\u0131 kullanarak zaman serisi verilerini y\u00f6netmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. “Hypertable” ad\u0131 verilen soyutlama katman\u0131 sayesinde, b\u00fcy\u00fck zaman serisi tablolar\u0131n\u0131 otomatik olarak zaman bazl\u0131 “chunk”lara b\u00f6ler. Bu chunk’lar, veri ya\u015fam d\u00f6ng\u00fcs\u00fc y\u00f6netimi, indeksleme ve \u00f6zellikle s\u0131k\u0131\u015ft\u0131rma i\u00e7in b\u00fcy\u00fck avantajlar sunar. PostgreSQL ekosistemiyle tam uyumlu olmas\u0131, mevcut ara\u00e7 ve becerilerden faydalanmay\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\n
TimescaleDB’nin s\u0131k\u0131\u015ft\u0131rma mekanizmas\u0131, zaman serisi verilerinin benzersiz \u00f6zelliklerinden faydalanarak hem disk alan\u0131ndan tasarruf etmeyi hem de sorgu performans\u0131n\u0131 optimize etmeyi hedefler. Geleneksel s\u0131k\u0131\u015ft\u0131rma y\u00f6ntemlerinden farkl\u0131 olarak, TimescaleDB, veriyi chunk baz\u0131nda kolonsal olarak depolar ve veri tiplerine \u00f6zel algoritmalar kullan\u0131r.<\/p>\n
TimescaleDB, hypertable’lar\u0131 otomatik olarak belirli zaman aral\u0131klar\u0131na (\u00f6rne\u011fin, bir g\u00fcn, bir hafta) g\u00f6re chunk’lara ay\u0131r\u0131r. S\u0131k\u0131\u015ft\u0131rma, bu chunk’lar \u00fczerinde uygulan\u0131r. Genellikle, en yeni ve aktif yazma yap\u0131lan chunk’lar s\u0131k\u0131\u015ft\u0131r\u0131lmazken, belirli bir ya\u015fa ula\u015fm\u0131\u015f (\u00f6rne\u011fin, 7 g\u00fcnl\u00fckten eski) chunk’lar otomatik olarak s\u0131k\u0131\u015ft\u0131r\u0131lmak \u00fczere i\u015faretlenir. Bu yakla\u015f\u0131m, yazma performans\u0131n\u0131 etkilemeden eski verilerin depolama ayak izini k\u00fc\u00e7\u00fclt\u00fcr.<\/p>\n
S\u0131k\u0131\u015ft\u0131rman\u0131n temelinde, verinin sat\u0131r bazl\u0131 depolamadan kolonsal depolamaya d\u00f6n\u00fc\u015ft\u00fcr\u00fclmesi yatar. Kolonsal depolama, ayn\u0131 veri tipindeki de\u011ferlerin art arda gelmesini sa\u011flayarak s\u0131k\u0131\u015ft\u0131rma algoritmalar\u0131n\u0131n \u00e7ok daha etkili \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r. TimescaleDB, farkl\u0131 veri tipleri i\u00e7in \u00f6zel s\u0131k\u0131\u015ft\u0131rma algoritmalar\u0131 kullan\u0131r:<\/p>\n
Bu optimizasyonlar sayesinde, benzer de\u011ferler veya art arda gelen de\u011ferler \u00e7ok daha az yer kaplar.<\/p>\n
TimescaleDB, s\u0131k\u0131\u015ft\u0131rma i\u015flemini otomatik hale getirmek i\u00e7in s\u0131k\u0131\u015ft\u0131rma politikalar\u0131 sunar. Bu politikalar, belirli bir ya\u015ftaki chunk’lar\u0131n (\u00f6rne\u011fin, 7 g\u00fcnden eski) otomatik olarak s\u0131k\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flar. Bu sayede, manuel m\u00fcdahaleye gerek kalmadan veritaban\u0131 s\u00fcrekli optimize edilir. Politikalar, TimescaleDB’de s\u0131k\u0131\u015ft\u0131rmay\u0131 etkinle\u015ftirmek ve y\u00f6netmek olduk\u00e7a basittir. \u0130\u015fte ad\u0131m ad\u0131m nas\u0131l yap\u0131laca\u011f\u0131:<\/p>\n \u0130lk ad\u0131m, s\u0131k\u0131\u015ft\u0131rmay\u0131 hypertable \u00fczerinde etkinle\u015ftirmektir. Bu i\u015flem, hangi s\u00fctunlar\u0131n s\u0131k\u0131\u015ft\u0131r\u0131laca\u011f\u0131n\u0131 ve s\u0131k\u0131\u015ft\u0131rma s\u0131ras\u0131nda verinin nas\u0131l s\u0131ralanaca\u011f\u0131n\u0131 da belirtmenizi sa\u011flar. <\/code> S\u0131k\u0131\u015ft\u0131rma politikas\u0131n\u0131 olu\u015fturarak, belirli bir ya\u015ftaki chunk'lar\u0131n otomatik olarak s\u0131k\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flayabilirsiniz.<\/p>\n <\/code> S\u0131k\u0131\u015ft\u0131rma ayarlar\u0131n\u0131z\u0131 ve s\u0131k\u0131\u015ft\u0131rma oranlar\u0131n\u0131z\u0131 izlemek i\u00e7in \u00e7e\u015fitli g\u00f6r\u00fcn\u00fcm ve fonksiyonlar\u0131 kullanabilirsiniz:<\/p>\n <\/code> Bir \u00fcretim ortam\u0131nda, s\u00fcrekli olarak IoT cihazlar\u0131ndan gelen telemetri verilerini (s\u0131cakl\u0131k, nem, bas\u0131n\u00e7, konum vb.) depolad\u0131\u011f\u0131m\u0131z bir senaryoyu ele alal\u0131m. Bu veritaban\u0131, yakla\u015f\u0131k 6 ayl\u0131k bir ge\u00e7mi\u015fi tutuyordu ve disk \u00fczerinde 150GB yer kapl\u0131yordu.<\/p>\n Veritaban\u0131m\u0131zda, saniyede ortalama 500-1000 kay\u0131t alan, yakla\u015f\u0131k 10.000 farkl\u0131 cihazdan gelen verileri i\u00e7eren bir hypertable bulunuyordu. Veri \u015femas\u0131 tipik olarak \u015funlar\u0131 i\u00e7eriyordu:<\/p>\n Ba\u015flang\u0131\u00e7ta, bu hypertable \u00fczerinde herhangi bir s\u0131k\u0131\u015ft\u0131rma etkin de\u011fildi ve 150GB'l\u0131k bir depolama alan\u0131 kullan\u0131yordu. Yedekleme i\u015flemleri 3-4 saat s\u00fcr\u00fcyordu ve eski verilere yap\u0131lan baz\u0131 analitik sorgular yava\u015f \u00e7al\u0131\u015fabiliyordu.<\/p>\n Mevcut veri yap\u0131s\u0131 ve sorgu desenleri g\u00f6z \u00f6n\u00fcne al\u0131narak a\u015fa\u011f\u0131daki s\u0131k\u0131\u015ft\u0131rma ayarlar\u0131 uyguland\u0131:<\/p>\n <\/code> Politika etkinle\u015ftirildikten ve eski chunk'lar s\u0131k\u0131\u015ft\u0131r\u0131ld\u0131ktan sonra, veritaban\u0131n\u0131n disk kullan\u0131m\u0131 dramatik bir \u015fekilde azald\u0131.<\/p>\n Bu %90'l\u0131k azalma, depolama maliyetlerinde do\u011frudan bir d\u00fc\u015f\u00fc\u015f sa\u011flad\u0131. Ayr\u0131ca, yedekleme s\u00fcreleri 3-4 saatten yakla\u015f\u0131k 30 dakikaya indi. Eski verilere y\u00f6nelik analitik sorgular, s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f veriler \u00fczerinde daha az I\/O gerektirdi\u011finden ve kolonsal depolaman\u0131n getirdi\u011fi avantajlar sayesinde belirgin \u015fekilde h\u0131zland\u0131. \u00d6zellikle belirli bir cihaz\u0131n uzun zaman aral\u0131\u011f\u0131ndaki verilerini \u00e7eken sorgular, daha \u00f6nce dakikalar s\u00fcren i\u015flemleri saniyeler i\u00e7inde tamamlamaya ba\u015flad\u0131.<\/p>\n TimescaleDB s\u0131k\u0131\u015ft\u0131rmas\u0131, sadece disk alan\u0131ndan tasarruf etmekle kalmaz, ayn\u0131 zamanda genel veritaban\u0131 performans\u0131n\u0131 ve operasyonel maliyetleri de \u00f6nemli \u00f6l\u00e7\u00fcde etkiler.<\/p>\n En bariz fayda, depolama alan\u0131ndaki azalmad\u0131r. %90'l\u0131k bir azalma, bulut sa\u011flay\u0131c\u0131lar\u0131nda depolama maliyetlerinde do\u011frudan bir d\u00fc\u015f\u00fc\u015f anlam\u0131na gelir. Ayr\u0131ca, daha az disk alan\u0131, daha k\u00fc\u00e7\u00fck sanal makine boyutlar\u0131 veya daha az fiziksel disk gereksinimi demektir.<\/p>\n S\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f verilere yap\u0131lan sorgular, \u00f6zellikle belirli s\u00fctunlar\u0131 hedefleyen veya zaman aral\u0131\u011f\u0131na g\u00f6re filtrelenen analitik sorgular i\u00e7in genellikle daha h\u0131zl\u0131d\u0131r. Bunun nedenleri:<\/p>\n Ancak, s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f verilere yap\u0131lan yazma i\u015flemleri veya Daha k\u00fc\u00e7\u00fck bir veritaban\u0131, yedekleme dosyalar\u0131n\u0131n boyutunu k\u00fc\u00e7\u00fclt\u00fcr ve yedekleme\/geri y\u00fckleme i\u015flemlerinin \u00e7ok daha h\u0131zl\u0131 tamamlanmas\u0131n\u0131 sa\u011flar. Bu, felaket kurtarma senaryolar\u0131nda RTO (Recovery Time Objective) hedeflerine ula\u015fmak i\u00e7in kritik bir avantajd\u0131r.<\/p>\n S\u0131k\u0131\u015ft\u0131rma ve s\u0131k\u0131\u015ft\u0131rmay\u0131 a\u00e7ma i\u015flemleri CPU \u00fczerinde bir y\u00fck olu\u015fturur. Ancak, bu y\u00fck genellikle zaman serisi i\u015f y\u00fcklerinde I\/O'dan kaynaklanan darbo\u011fazlar\u0131 hafifletmek i\u00e7in kabul edilebilir bir takas olarak g\u00f6r\u00fcl\u00fcr. Politikalar genellikle d\u00fc\u015f\u00fck kullan\u0131m zamanlar\u0131nda \u00e7al\u0131\u015facak \u015fekilde ayarlanabilir.<\/p>\n TimescaleDB s\u0131k\u0131\u015ft\u0131rmas\u0131ndan en iyi \u015fekilde faydalanmak i\u00e7in baz\u0131 en iyi uygulamalar\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmak \u00f6nemlidir.<\/p>\n Bu ayarlar\u0131, ger\u00e7ek sorgu desenlerinizi ve veri da\u011f\u0131l\u0131m\u0131n\u0131z\u0131 analiz ederek belirlemelisiniz.<\/p>\n S\u0131k\u0131\u015ft\u0131rma politikalar\u0131n\u0131, veri saklama (retention) politikalar\u0131yla birlikte kullanmak, veri ya\u015fam d\u00f6ng\u00fcs\u00fc y\u00f6netimini optimize eder. \u00d6rne\u011fin, 3 g\u00fcnden eski verileri s\u0131k\u0131\u015ft\u0131rabilir, 30 g\u00fcnden eski verileri ise tamamen silebilirsiniz.<\/p>\n <\/code> S\u0131k\u0131\u015ft\u0131rmay\u0131 etkinle\u015ftirdikten sonra, veritaban\u0131 performans\u0131n\u0131 ve disk kullan\u0131m\u0131n\u0131 d\u00fczenli olarak izleyin. TimescaleDB s\u0131k\u0131\u015ft\u0131rmas\u0131, zaman serisi verilerinin y\u00f6netimi i\u00e7in devrim niteli\u011finde bir \u00f6zelliktir. Ger\u00e7ek bir \u00fcretim ortam\u0131nda 150GB'l\u0131k bir veri setini 15GB'a d\u00fc\u015f\u00fcrerek %90'l\u0131k bir azalma elde etmemiz, bu teknolojinin g\u00fcc\u00fcn\u00fc ve etkinli\u011fini a\u00e7\u0131k\u00e7a ortaya koymaktad\u0131r. Bu sadece depolama maliyetlerinde \u00f6nemli bir tasarruf sa\u011flamakla kalmam\u0131\u015f, ayn\u0131 zamanda yedekleme s\u00fcrelerini k\u0131saltm\u0131\u015f ve eski verilere y\u00f6nelik analitik sorgular\u0131n performans\u0131n\u0131 art\u0131rm\u0131\u015ft\u0131r. Do\u011fru yap\u0131land\u0131rma ve izleme ile TimescaleDB s\u0131k\u0131\u015ft\u0131rmas\u0131, zaman serisi veritabanlar\u0131n\u0131z\u0131n \u00f6l\u00e7eklenebilirli\u011fini, performans\u0131n\u0131 ve maliyet etkinli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde iyile\u015ftirebilir. E\u011fer zaman serisi verileriyle \u00e7al\u0131\u015f\u0131yorsan\u0131z ve depolama veya performans sorunlar\u0131 ya\u015f\u0131yorsan\u0131z, TimescaleDB s\u0131k\u0131\u015ft\u0131rmas\u0131n\u0131 de\u011ferlendirmeniz \u015fiddetle tavsiye edilir.<\/p>\n S\u0131k\u0131\u015ft\u0131rma, zaman damgalar\u0131, say\u0131sal de\u011ferler (INTEGER, REAL, DOUBLE PRECISION) ve tekrarlayan metin (TEXT, VARCHAR) de\u011ferleri i\u00e7in en etkilidir. Rastgele veya benzersiz metin de\u011ferleri i\u00e7in s\u0131k\u0131\u015ft\u0131rma oran\u0131 daha d\u00fc\u015f\u00fck olabilir.<\/p>\n Hay\u0131r, genellikle tam tersi olur. \u00d6zellikle belirli s\u00fctunlar\u0131 hedefleyen veya zaman aral\u0131\u011f\u0131na g\u00f6re filtrelenen analitik sorgular, s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f veriler \u00fczerinde daha az I\/O gerektirdi\u011finden daha h\u0131zl\u0131 \u00e7al\u0131\u015f\u0131r. Ancak, t\u00fcm s\u00fctunlar\u0131 okuyan veya s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f veriler \u00fczerinde s\u0131k\u00e7a S\u0131k\u0131\u015ft\u0131rma ve s\u0131k\u0131\u015ft\u0131rmay\u0131 a\u00e7ma i\u015flemleri CPU yo\u011fun i\u015flemlerdir. Ancak, TimescaleDB bu i\u015flemleri genellikle arka plan i\u015f\u00e7ileri (background workers) arac\u0131l\u0131\u011f\u0131yla yapar ve I\/O maliyetindeki \u00f6nemli d\u00fc\u015f\u00fc\u015f genellikle CPU \u00fczerindeki ek y\u00fck\u00fc telafi eder. Modern CPU'lar bu t\u00fcr i\u015flemleri olduk\u00e7a verimli bir \u015fekilde halledebilir.<\/p>\n Evet, Evet, s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f bir chunk'\u0131 add_compression_policy<\/code> fonksiyonu ile kolayca tan\u0131mlanabilir.<\/p>\nS\u0131k\u0131\u015ft\u0131rmay\u0131 Uygulama: Ad\u0131m Ad\u0131m Rehber<\/h2>\n
S\u0131k\u0131\u015ft\u0131rmay\u0131 Etkinle\u015ftirme<\/h3>\n
segmentby<\/code> ve orderby<\/code> parametreleri, s\u0131k\u0131\u015ft\u0131rma oran\u0131n\u0131 ve sorgu performans\u0131n\u0131 do\u011frudan etkiler.<\/p>\n\nALTER TABLE your_hypertable SET (\n timescaledb.compress = TRUE,\n timescaledb.compress_segmentby = 'device_id',\n timescaledb.compress_orderby = 'time DESC'\n);\n<\/pre>\n
\nYukar\u0131daki \u00f6rnekte:<\/p>\n\n
timescaledb.compress = TRUE<\/code>: S\u0131k\u0131\u015ft\u0131rmay\u0131 etkinle\u015ftirir.<\/li>\ntimescaledb.compress_segmentby = 'device_id'<\/code>: Veriyi device_id<\/code> s\u00fctununa g\u00f6re grupland\u0131rarak s\u0131k\u0131\u015ft\u0131r\u0131r. Bu, ayn\u0131 cihazdan gelen verilerin bir arada olmas\u0131n\u0131 sa\u011flayarak daha iyi s\u0131k\u0131\u015ft\u0131rma oranlar\u0131 elde edilmesine yard\u0131mc\u0131 olur.<\/li>\ntimescaledb.compress_orderby = 'time DESC'<\/code>: S\u0131k\u0131\u015ft\u0131rma s\u0131ras\u0131nda veriyi time<\/code> s\u00fctununa g\u00f6re azalan s\u0131rada s\u0131ralar. Bu, belirli zaman aral\u0131klar\u0131ndaki sorgular\u0131n daha h\u0131zl\u0131 \u00e7al\u0131\u015fmas\u0131na katk\u0131da bulunabilir.<\/li>\n<\/ul>\nS\u0131k\u0131\u015ft\u0131rma Politikas\u0131 Olu\u015fturma<\/h3>\n
\nSELECT add_compression_policy('your_hypertable', INTERVAL '7 days');\n<\/pre>\n
\nBu komut, your_hypertable<\/code> \u00fczerinde 7 g\u00fcnden eski t\u00fcm chunk'lar\u0131n otomatik olarak s\u0131k\u0131\u015ft\u0131r\u0131lmas\u0131 i\u00e7in bir politika ekler. TimescaleDB, arka planda bir i\u015f\u00e7i (worker) kullanarak bu i\u015flemi periyodik olarak ger\u00e7ekle\u015ftirir.<\/p>\nS\u0131k\u0131\u015ft\u0131rma Durumunu \u0130zleme<\/h3>\n
\n-- Hypertable'\u0131n s\u0131k\u0131\u015ft\u0131rma ayarlar\u0131n\u0131 kontrol etme\nSELECT * FROM timescaledb_information.compression_settings WHERE hypertable_name = 'your_hypertable';\n\n-- S\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f chunk'lar\u0131n istatistiklerini g\u00f6rme\nSELECT * FROM timescaledb_information.compressed_hypertable_stats WHERE hypertable_name = 'your_hypertable';\n<\/pre>\n
\nBu sorgular, hangi chunk'lar\u0131n s\u0131k\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131n\u0131, ne kadar yer kazand\u0131\u011f\u0131n\u0131z\u0131 ve s\u0131k\u0131\u015ft\u0131rma oranlar\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 olur.<\/p>\nGer\u00e7ek \u00dcretim Verisinde %90 Azalma: Vaka \u00c7al\u0131\u015fmas\u0131<\/h2>\n
Senaryo ve \u0130lk Durum<\/h3>\n
\n
time<\/code> (TIMESTAMPTZ)<\/li>\ndevice_id<\/code> (UUID)<\/li>\ntemperature<\/code> (REAL)<\/li>\nhumidity<\/code> (REAL)<\/li>\npressure<\/code> (REAL)<\/li>\nlatitude<\/code> (REAL)<\/li>\nlongitude<\/code> (REAL)<\/li>\nUygulanan S\u0131k\u0131\u015ft\u0131rma Ayarlar\u0131<\/h3>\n
\nALTER TABLE iot_telemetry SET (\n timescaledb.compress = TRUE,\n timescaledb.compress_segmentby = 'device_id',\n timescaledb.compress_orderby = 'time DESC, device_id'\n);\n\nSELECT add_compression_policy('iot_telemetry', INTERVAL '3 days');\n<\/pre>\n
\nBurada compress_segmentby = 'device_id'<\/code> se\u00e7imi, ayn\u0131 cihaza ait t\u00fcm verilerin bir arada gruplanarak s\u0131k\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flad\u0131. Bu, device_id<\/code> tekrarlayan bir s\u00fctun oldu\u011fu i\u00e7in s\u0131k\u0131\u015ft\u0131rma oran\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rd\u0131. compress_orderby = 'time DESC, device_id'<\/code> ise, hem zaman bazl\u0131 sorgular\u0131n performans\u0131n\u0131 art\u0131rmay\u0131 hem de ayn\u0131 cihazdan gelen verilerin zaman i\u00e7inde s\u0131ral\u0131 olmas\u0131n\u0131 hedefledi. S\u0131k\u0131\u015ft\u0131rma politikas\u0131, 3 g\u00fcnden eski verilerin otomatik olarak s\u0131k\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flad\u0131.<\/p>\nSonu\u00e7lar ve Veri Azalmas\u0131<\/h3>\n
\n
S\u0131k\u0131\u015ft\u0131rman\u0131n Performans ve Maliyet \u00dczerindeki Etkileri<\/h2>\n
Disk Alan\u0131 Tasarrufu<\/h3>\n
Sorgu Performans\u0131<\/h3>\n
\n
UPDATE<\/code>\/DELETE<\/code> i\u015flemleri daha yava\u015f olabilir, \u00e7\u00fcnk\u00fc veri \u00f6nce a\u00e7\u0131lmal\u0131, de\u011fi\u015ftirilmeli ve sonra tekrar s\u0131k\u0131\u015ft\u0131r\u0131lmal\u0131d\u0131r. Bu nedenle, s\u0131k\u0131\u015ft\u0131rma genellikle eski ve nadiren de\u011fi\u015fen veriler i\u00e7in uygulan\u0131r.<\/p>\nYedekleme ve Geri Y\u00fckleme S\u00fcreleri<\/h3>\n
CPU Kullan\u0131m\u0131<\/h3>\n
En \u0130yi Uygulamalar ve \u0130pu\u00e7lar\u0131<\/h2>\n
Do\u011fru S\u0131k\u0131\u015ft\u0131rma Ayarlar\u0131n\u0131 Se\u00e7me<\/h3>\n
compress_segmentby<\/code> ve compress_orderby<\/code> parametreleri, s\u0131k\u0131\u015ft\u0131rma oran\u0131n\u0131 ve sorgu performans\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde etkiler.<\/p>\n\n
compress_segmentby<\/code>:<\/b> Genellikle cihaz kimli\u011fi, sens\u00f6r kimli\u011fi, kullan\u0131c\u0131 kimli\u011fi gibi tekrarlayan ve sorgular\u0131n\u0131zda s\u0131k\u00e7a filtreledi\u011finiz bir s\u00fctunu se\u00e7in. Bu, ayn\u0131 de\u011ferlere sahip verilerin bir araya gelmesini sa\u011flayarak s\u0131k\u0131\u015ft\u0131rma oran\u0131n\u0131 art\u0131r\u0131r.<\/li>\ncompress_orderby<\/code>:<\/b> Sorgular\u0131n\u0131zda s\u0131k\u00e7a kulland\u0131\u011f\u0131n\u0131z s\u0131ralama d\u00fczenine uygun bir s\u00fctun se\u00e7in (genellikle time DESC<\/code>). Bu, sorgular\u0131n s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f veri \u00fczerinde daha verimli \u00e7al\u0131\u015fmas\u0131na yard\u0131mc\u0131 olabilir. Birden fazla s\u00fctun da belirtebilirsiniz.<\/li>\n<\/ul>\nVeri Saklama Politikalar\u0131yla Entegrasyon<\/h3>\n
\nSELECT add_retention_policy('your_hypertable', INTERVAL '30 days');\n<\/pre>\n
\nBu, hem depolama maliyetini d\u00fc\u015f\u00fcr\u00fcr hem de veritaban\u0131n\u0131n boyutunu y\u00f6netilebilir s\u0131n\u0131rlar i\u00e7inde tutar.<\/p>\nS\u0131k\u0131\u015ft\u0131rma Sonras\u0131 \u0130zleme<\/h3>\n
timescaledb_information.compressed_hypertable_stats<\/code> gibi g\u00f6r\u00fcn\u00fcmleri kullanarak s\u0131k\u0131\u015ft\u0131rma oranlar\u0131n\u0131 ve s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f veri boyutunu takip edin. Ayr\u0131ca, sorgu performans\u0131n\u0131 ve CPU kullan\u0131m\u0131n\u0131 da g\u00f6zlemleyerek herhangi bir olumsuz etki olup olmad\u0131\u011f\u0131n\u0131 kontrol edin.<\/p>\nSonu\u00e7<\/h2>\n
S\u0131k Sorulan Sorular (SSS)<\/h2>\n
S\u0131k\u0131\u015ft\u0131rma hangi veri tipleri i\u00e7in en etkilidir?<\/h3>\n
S\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f verilere sorgu yapmak yava\u015flar m\u0131?<\/h3>\n
UPDATE<\/code>\/DELETE<\/code> yapan i\u015flemler biraz daha yava\u015f olabilir.<\/p>\nS\u0131k\u0131\u015ft\u0131rma ne kadar CPU kullan\u0131r?<\/h3>\n
Mevcut verilerimi s\u0131k\u0131\u015ft\u0131rabilir miyim?<\/h3>\n
ALTER TABLE ... SET (timescaledb.compress = TRUE, ...)<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131ktan ve bir s\u0131k\u0131\u015ft\u0131rma politikas\u0131 ekledikten sonra, politika taraf\u0131ndan belirlenen ya\u015fa uygun mevcut chunk'lar otomatik olarak s\u0131k\u0131\u015ft\u0131r\u0131lacakt\u0131r. Ayr\u0131ca, compress_chunk()<\/code> fonksiyonunu kullanarak belirli bir chunk'\u0131 manuel olarak da s\u0131k\u0131\u015ft\u0131rabilirsiniz.<\/p>\nS\u0131k\u0131\u015ft\u0131rmay\u0131 geri alabilir miyim?<\/h3>\n
decompress_chunk()<\/code> fonksiyonu ile manuel olarak a\u00e7abilirsiniz. Bir hypertable \u00fczerindeki s\u0131k\u0131\u015ft\u0131rmay\u0131 tamamen devre d\u0131\u015f\u0131 b\u0131rakmak i\u00e7in ALTER TABLE your_hypertable SET (timescaledb.compress = FALSE);<\/code> komutunu kullanabilirsiniz. Ancak, bu mevcut s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f chunk'lar\u0131 otomatik olarak a\u00e7maz, sadece yeni chunk'lar\u0131n s\u0131k\u0131\u015ft\u0131r\u0131lmamas\u0131n\u0131 sa\u011flar.<\/p>\n","protected":false},"excerpt":{"rendered":"TimescaleDB S\u0131k\u0131\u015ft\u0131rma: 150GB’dan 15GB’a \u0130nan\u0131lmaz Bir Yolculuk (%90 Azalma, Ger\u00e7ek \u00dcretim Verisi)\nZaman serisi verileri, modern uygulamalar\u0131n ve s…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-38591","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n