basit ve hızlı olması açısından xml kullanabilirsin hocam. kendine bir xml helper yazarsın o şekilde devam edebilirsin.. xml; semi-strucred bir yapıya sahip Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

. ozgunlu tarafından 06/May/15 13:25 tarihinde düzenlenmiştir Hello, i am nothing. I come from Neverland.

statik verileri web. config - app. config de tutmak idealdir. Eğer dinamik veri olsaydı bir arayüz ile ekle güncelle sil operasyonlarını yapman gerekseydi veritabanı kesinlikle şart her bakımdan. yedekleme olsun güvenlik olsun.. Paslanmış bir uygulama geliştirici.. #AnalistŞart

Hacı paylaştığın link de bahsettiğim şeyi sylüyor. Sen "As a general rule, databases are slower than files." bunu okuyup linki paylaşmışsın ancak bu teorik bir cümledir, as a general rule. Burda bahsettiği dosyayı açıp okumak, ben istediğin datayı almak ile ilgili yazıyorum. ve şunları da okuman gerek: Unless you're very clever, you can't write a cache as good as that of a DB server. Eğer sen bir dbms gibi cache ve indexing yapamazsan ki bundan bahsediyorum, okuma hızın her zaman daha yavaş olacaktır. İlk mesajımda da syledim, burda datanın tümünü okumak gibi düşünme, istediğin datayı okumak gibi düşün. işin içinde index ve query var yani. ok? Do you need flexibility in order to easily query the data from a variety of angles? Bak bu soruyu sorman lazım kendine. Yani şyle düşün bir dosyada big data var ve sen buraya insert yapıyorsun. Şimdi sen data alacaksın ya da update edeceksin. Şu soruyu sor kendine, bu big data içinde, istediğim datayı nasıl alırım? istediğim datayı nasıl update ederim? Bu soruların cevabını dbms'siz verebiliyorsan yaz kodunu paylaş zaten o zaman temel bir dbms yazmış olacaksın iş yine dbms'e dnmüş olacak. mongodb mysql vs vs fark etmez. Sen sıfırdan dosyaya data kaydedip buna insert update istediğini fetch olaylarıyla bir dbms'ten çok daha fazla zaman harcarsın Son olarak sen kimsin seninle sidik yarıştıracam? Bak ne demişim; hocam çalıştığım yerde big datayla uğraşıcaz da bu soruyu bi yerde kullanmak için sormadım :) Big Data olayı nerden çıktı anlamadım? Benim sorumda bulunmuyor. İkincisi ben. txt uzantısından da hiç bahsetmedim? Dosyadan bahsediyorum, json olabilir, xml olabilir ya da php dosyası olabilir basitinden. Yani ben mesela çok dilli bir sistem hazırlıyorum diyelim. Burdaki değişkenleri dosyada tutmak ile veritabanında tutmak arasındaki erişim hızını kastettim diye farzet. Ya da imageları veritabanına blob türünde mi tutunca hızlı erişirim yoksa dosya da mı. Ben tutup da sana. txt dosyada "a" harfini arıcam diye bişey demedim ki? Erişim hızını merak ettim sordum, db için bir connection olayı oluyor, bu noktada file' a erişim arasındaki hız farkı nedir, biri bunla ilgili performans testi yapmışsa koymuşsa link alıyım diye sordum? selamlar, uzatmıcam. yazma o yüzden cevap da yazmıcam. sen haklısın :) ozgunlu tarafından 06/May/15 13:50 tarihinde düzenlenmiştir Hello, i am nothing. I come from Neverland.

Cache için diyorsan şyle birşey buldum. http://surniaulula.com/2012/12/04/memcached-vs-disk-cache/ Bu imzayı her grdüğünüzde 4gb kotanızın 0,00000358559191226959228515625 azalmaktadır. Bilerek ve istenerek bu imza yapılmıştır. Amaç kotanızı smürmektir

"Modlar silsin" diyor mürit. Modlar silin

elbette var hocam deneyebilirsin istersen... rasgele verilerle doldur milyonlarca sonra test edip farkını gzle :) nosql yapılarına da bakabilirsin, onların da hızlı olmasının sebebi bu aslında.. bunlar ilişkisel yapılar değil, karmaşık sorgular yapamazsın, join kullanamazsın v. s. hocam onu yapcam akşam da :) sebepleri neler var mı bi fikrin? Hello, i am nothing. I come from Neverland.

hocam xml de farkettiğin üzerine metin tabanlı tutuluyor ve direk okuma yapabiliyorsun ama ilişkisel veritabanlarında iş yle değil, bir sürü faktr var, verilerin kaydediliş şekilleri, keyler ... bunlar gibi faktrler hızı belirler. Ama bu hız muhtemelen senin projelerinde pek gzle grülür bir şey olmayacak. Çünkü kaydedeceğin dataların boyutları çok fazla büyük değildir diye düşünüyorum, büyük bir firma olsan zaten çzüm arayışlarına girersin ama küçük ve orta düzeyler için dbms ler yeterlidir. Ama bunu xml ile de yapabilirsin. Dediğim gibi çok fazla farkı olmayacak senin için... küçük datalarda bu hız farkları ms civarındadır. verilerinde her hangi bir yapı yoksa direk metin dosyasında tutabilirsin, yapıların varsa o zaman xml de tutabilirsin, yapıların var ve aynı zamanda kompleks sorgular yapacaksan dbms kullanabilirsin Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

Avantajdan ziyade aralarında bir hız farkı var mıdır, bunu merak ediyorum? Hello, i am nothing. I come from Neverland.

Tercih meselesi, Dosya sistemi de bir veritabanıdır hocam. Statik datadan kastın ne? resim falan dolduracaksan le 100.000 leri bulmayacaksa dosya sistemi iyi bir seçenek. Nush ile uslanmayanı etmeli tekdir, Tekdir ile uslanmayanın hakkı ktektir!

Son olarak şunu syleyim, datanın büyüklüğünü düşünelim dosyadan okurkendata büyüdükçe; dosyayı açma ve istediğin değere ulaşma süren, datayla doğru orantılı büyür. dbms'te, cache ve indexing yapılmışsa, bağlantı hızın sabit, cache var, index varsa, her eklenen değer ulaşma süresini o oranda artırmaz, bunun için dbmslerin cache ve index algoritmaları var. mesela en basitinden btree algoritması bu algoritma sayesinde +1 data +1 iteration getirmez. bu durumda baktığın zaman data ne kadar büyük olursa olsun neredeyse hiçbir şey artmıyro, neredeyse dememin sebebi btree algoritması ve cache sayesinde. Tabi her şeyde olduğu gibi limitler var, bu durum dosyada da var. bunun için mongodb gibi çzümler de var. dosyadan okusan +1 data +1 iterasyon olacak. Ben konuya 10luk bir arraye keyiyle ulaşmak gibi bakmadım o yüzden bunları yazdım

Sen bütün farklı value'ları key olarak tutup $arr => x şeklinde bir matrix oluşturursan da bu sefer her sorgu sana tek bir değer dndürmüş olur. Multi sorgular için dngü yapman gerekir yine parse'a dner iş. Static data olsa ne kadar static olabilir. İlla ki update insert delete olacak o zaman yine dbms'in avantajlarını ararsın

conf. vb static datalar genelde dizi olarak tutulur. a. php return ; b. php $eleman = require ; echo $eleman ; Hybris tarafından 04/May/15 23:07 tarihinde düzenlenmiştir agile isn't how fast you can go, it's how fast you can turn.

Hoca seninle sidik yarıştırma değil de ben query atacağın durumlardan bahsediyorum. siktirli konuşma... senin, hesabımı banlatmak istemiyorum senin gibi biri için. teknik bir şeyler yazmaya çalıştım, zaten language gibi bir şey için yani bir tane array, keyleri valueları var bunu tutacaksın bir yerde sonra kod içinde key'iyle ulaşacaksın falan. Bunun için bu soruyu sormaya bile gerek yok. static data bile olsa update insert bile olmasa, data okumak demek bilgi çekmek demek, sen bütün datayı bir anda okuyacaksan zaten array olarak kaydeder sonra hepsini phpden vs okursun, ben sana istediğin datayı almaktan bahsediyorum, genel soruya genel cevap veriyorum anladım, kusura bakma. ama üslubun başta ktüydü. benim bahsetmediğim şeyleri anlatmışsın. o linki biri bişeyler ğrensin diye paylaştım. senin lafınla alakalı değildi. muhabbeti geçtiği için ozgunlu tarafından 06/May/15 13:50 tarihinde düzenlenmiştir Hello, i am nothing. I come from Neverland.

Bence sen en iyi bildiğin şekilde yap. Sonuçta data senin. Nasıl, ne şekilde olduğunu, ne kadar komplex olduğunu, ileride insert update olacak mı olmayacak mı en iyi sen bilirsin. En iyi bildiğin, en hızlı şekilde yaz kodunu sonra test et. sonuçlarını da yaz ki biz de bilelim. Ben de data işlerinde dbms çok az kullanıyorum ancak datanın komplexliği bir yere kadar, ondan sonra dbms'e muhtaç oluyorsun. 10luk bir arrayda istediğin key'e anında ulaşırsın da big data deyince datanın bulunduğu dosyayı açmak okumak sonra istediğin keye ulaşmak yle 10luk array gibi olmaz BENCE

Hoca seninle sidik yarıştırma değil de ben query atacağın durumlardan bahsediyorum. siktirli konuşma... senin, hesabımı banlatmak istemiyorum senin gibi biri için. teknik bir şeyler yazmaya çalıştım, zaten language gibi bir şey için yani bir tane array, keyleri valueları var bunu tutacaksın bir yerde sonra kod içinde key'iyle ulaşacaksın falan. Bunun için bu soruyu sormaya bile gerek yok. static data bile olsa update insert bile olmasa, data okumak demek bilgi çekmek demek, sen bütün datayı bir anda okuyacaksan zaten array olarak kaydeder sonra hepsini phpden vs okursun, ben sana istediğin datayı almaktan bahsediyorum, genel soruya genel cevap veriyorum alp tarafından 06/May/15 13:48 tarihinde düzenlenmiştir

Hacı paylaştığın link de bahsettiğim şeyi sylüyor. Sen "As a general rule, databases are slower than files." bunu okuyup linki paylaşmışsın ancak bu teorik bir cümledir, as a general rule. Burda bahsettiği dosyayı açıp okumak, ben istediğin datayı almak ile ilgili yazıyorum. ve şunları da okuman gerek: Unless you're very clever, you can't write a cache as good as that of a DB server. Eğer sen bir dbms gibi cache ve indexing yapamazsan ki bundan bahsediyorum, okuma hızın her zaman daha yavaş olacaktır. İlk mesajımda da syledim, burda datanın tümünü okumak gibi düşünme, istediğin datayı okumak gibi düşün. işin içinde index ve query var yani. ok? Do you need flexibility in order to easily query the data from a variety of angles? Bak bu soruyu sorman lazım kendine. Yani şyle düşün bir dosyada big data var ve sen buraya insert yapıyorsun. Şimdi sen data alacaksın ya da update edeceksin. Şu soruyu sor kendine, bu big data içinde, istediğim datayı nasıl alırım? istediğim datayı nasıl update ederim? Bu soruların cevabını dbms'siz verebiliyorsan yaz kodunu paylaş zaten o zaman temel bir dbms yazmış olacaksın iş yine dbms'e dnmüş olacak. mongodb mysql vs vs fark etmez. Sen sıfırdan dosyaya data kaydedip buna insert update istediğini fetch olaylarıyla bir dbms'ten çok daha fazla zaman harcarsın alp tarafından 06/May/15 13:36 tarihinde düzenlenmiştir

hocam xml de farkettiğin üzerine metin tabanlı tutuluyor ve direk okuma yapabiliyorsun ama ilişkisel veritabanlarında iş yle değil, bir sürü faktr var, verilerin kaydediliş şekilleri, keyler ... bunlar gibi faktrler hızı belirler. Ama bu hız muhtemelen senin projelerinde pek gzle grülür bir şey olmayacak. Çünkü kaydedeceğin dataların boyutları çok fazla büyük değildir diye düşünüyorum, büyük bir firma olsan zaten çzüm arayışlarına girersin ama küçük ve orta düzeyler için dbms ler yeterlidir. Ama bunu xml ile de yapabilirsin. Dediğim gibi çok fazla farkı olmayacak senin için... küçük datalarda bu hız farkları ms civarındadır. verilerinde her hangi bir yapı yoksa direk metin dosyasında tutabilirsin, yapıların varsa o zaman xml de tutabilirsin, yapıların var ve aynı zamanda kompleks sorgular yapacaksan dbms kullanabilirsin hocam çalıştığım yerde big datayla uğraşıcaz da bu soruyu bi yerde kullanmak için sormadım :) sadece merakımdan, aklıma geldi durduk yere. Eve geçince bir hız testi yapıp paylaşırım burda. Bakalım neler çıkcak ortaya. Ama bu farka etki eden faktrler ilgilendiriyordu beni. Yani db' ye bağlanmak ile bir dosyayı açma arasındaki fark vs. neyse bi bakayım ben, çıkarsa bişiler yazarım :) Hello, i am nothing. I come from Neverland.

edit. ozgunlu tarafından 06/May/15 13:19 tarihinde düzenlenmiştir Hello, i am nothing. I come from Neverland.

Session id yi db ile o dosyayı okutacağı alana sok , veriyi dosyadan okut . Boyut ve tahmini kullanıcı sayısına gre hareket etmek lazım. Bizde 80-90mb data dosyası olabiliyor sorguyu sunucuda bir lokasyona xls olarak çıkarıp çıkan dosyayı xls yapıp sıkıştırılmış sürümünü cliente gnderip client bilgisayarda program içinden yine bir lokasyona açtırıp ekranda okutmak çok daha avantajlı olabiliyor. Boyut ve kullanıcı sayısı belirler diyelim. fazla da düşünüp kendini üzme, hayat bir şekilde geçip gidiyor.

sqlite kullan :)

unbalanced bunu yazdı hocam xml de farkettiğin üzerine metin tabanlı tutuluyor ve direk okuma yapabiliyorsun ama ilişkisel veritabanlarında iş yle değil, bir sürü faktr var, verilerin kaydediliş şekilleri, keyler ... bunlar gibi faktrler hızı belirler. Ama bu hız muhtemelen senin projelerinde pek gzle grülür bir şey olmayacak. Çünkü kaydedeceğin dataların boyutları çok fazla büyük değildir diye düşünüyorum, büyük bir firma olsan zaten çzüm arayışlarına girersin ama küçük ve orta düzeyler için dbms ler yeterlidir. Ama bunu xml ile de yapabilirsin. Dediğim gibi çok fazla farkı olmayacak senin için... küçük datalarda bu hız farkları ms civarındadır. verilerinde her hangi bir yapı yoksa direk metin dosyasında tutabilirsin, yapıların varsa o zaman xml de tutabilirsin, yapıların var ve aynı zamanda kompleks sorgular yapacaksan dbms kullanabilirsin hocam çalıştığım yerde big datayla uğraşıcaz da bu soruyu bi yerde kullanmak için sormadım :) sadece merakımdan, aklıma geldi durduk yere. Eve geçince bir hız testi yapıp paylaşırım burda. Bakalım neler çıkcak ortaya. Ama bu farka etki eden faktrler ilgilendiriyordu beni. Yani db' ye bağlanmak ile bir dosyayı açma arasındaki fark vs. neyse bi bakayım ben, çıkarsa bişiler yazarım :) oo big data hangi firma ne için kullanıcaksınız big datayı :) bizide firmada big data ile uğraşıyoruz tabi daha çok iş zekası üzerine :)

Birşeyi merak ediyorum, Statik datayı veritabanında mı tutmalı yoksa bir dosyada mı? Yani asıl merak ettiğim olay, datayı veritabanından okumak mı hızlıdır yoksa dosyadan mı? Hello, i am nothing. I come from Neverland.

dosyadan okumak daha avantajlı hocam veritabanına ne kadar az yük binerse o kadar iyidir. Kasnak yuvarlandı elek oldu, eski orospular melek oldu...

unbalanced xml demiş bende json formatında tut diyim daha light ve xml deki zellikler mevcut daha hızlı bir okuma yapabilirsin.

Teşekkür ederim herkese, sanırım pek bir fark oluşturmuyorlar :) dediğim gibi sadece meraktan sordum, durduk yere geldi aklıma. Bu arada NoSQL yapıları anlatan çok hoş bir makale var; https://www.linkedin.com/pulse/mongodb-ile-%C3%A7al%C4%B1%C5%9Fmak-binnur-kurt Hello, i am nothing. I come from Neverland.

Hoca nasıl bir fark oluşturmuyorlar? Sen big data dediğin verileri kaydet bir txt dosyasına, ben de herhangi bir dbms'e kaydedeyim. Sonra müritler desin ki, şu dataları getirin. Bakalım kimin kodu daha hızlı getiriyor dataları. Sen o txt dosyasından data çekmek için gerekli kodu yazamazsın bile. Yazsan da ben max. 2 satırla istenen her datayı en hızlı şekilde getirirken sen loop'ların içinde kaybolur; saniyeler, belki dakikalar harcarsın. Sen txt'den, dbms'ten daha hızlı data okuyacağını iddia et ben senin alnını karışlarım. Zaten paylaştığın link de mongodb linki, o da bir dbms. Ben query deyince sen nosql paylaşmışsın ancak mongodb'ye gnderdiklerin de query oluyor. sql değil ancak sonuçta şunu diyorsun "Şunu getir, şunu filtrele" dbms'lerde genel fetch mantığı indexler üzerine kuruludur. Onlar datayı şu an bilinen ve usable en iyi yntemlerle indexler, fetch ederken bu algoritmayı kullanıp işlemleri hızlandırır. dbms datayı btree'de tutar mesela bu da bir kayıt ararken search hızını kat kat hızlandırır. btree'ye gre indexlenmişse data rnek olarak, 128 kayıt varsa istenen bir kayıt max. 2^n => 7 iteration'da gelir. Diğer türlü 128 kayıt test edilmesi lazım ki bu diğerine gre çok daha fazla zaman alır alp tarafından 06/May/15 13:16 tarihinde düzenlenmiştir

Hoca şu mesajları okuyup bir fark yok diyorsan bence sen üslubunu düzelt :)

Veri tabanı dediğin şey de arkada dosya tutuyor sonuçta :) İhtiyaca bağlı bir durum. Yani indexleme, sıralama, listeleme vb ihtiyaçların yoksa dosya daha ideal. Ama bu tarz şeyler gerekince veritabanı sistemleri farkedilir oranda hızlı olacaktır. Bu arada big data muhabbeti dnmüş baya grünce ekleyeyim dedim. Big Data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it. There are 10 types of people in the world. Those who knows binary and those who dont...

hoca tabii ki veritabanında tutmak daha avantajlı. Big data diyorsun. Bunu sadece datayı kaydetmek ve tümünü okumak olarak düşünme. Gün gelecek o dataya query atman gerekecek. Tüm datayı al içinden ayıkla diye bir şey yaparsan kat kat yavaşlar okuma hızın. Günümüz db'lerinden bir şey kullanırsan, şu datayı istiyorum dersen o datayı alırsın. db arka plandaki işleri senin için optimize eder en hızlı şekilde getirir. Sen sadece query'ini daha hızlı çalışacak şekilde ayarlarsın o kadar

Bence en temizi Database. Her şeyin bir yerde durması daha iyi. Ama unbalanced in dediği gibi xml de en hızlısı metin okuyorsun sonuçta. :) https://www.youtube.com/watch?v=WC3-71NKwPw

elbette var hocam deneyebilirsin istersen... rasgele verilerle doldur milyonlarca sonra test edip farkını gzle :) nosql yapılarına da bakabilirsin, onların da hızlı olmasının sebebi bu aslında.. bunlar ilişkisel yapılar değil, karmaşık sorgular yapamazsın, join kullanamazsın v. s. Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

Kod içinde nceden oluşturulmuş key-value şeklined bir array varsa, sen dil altyapısı falan kuruyorsan $arrary şeklinde hızlıca ulaşırsın, bunun için db'ye falan gerek yok da sylemek istediğim static de olsa big dataysa, byle dil gibi basit bir yapı değilse işin içine farklı queryler girecek, yani her istediğine key ile ulaşamayacaksın, valuedan da filtrelemen gereken şeyler olacak bu durumda db daha hızlı olur diğer türlü kurduğun algoritma sana zaman kaybettirir. Dilse yapmak istediğin hocam zaten genel olarak olay php vs içinde tutmaktır array'i sonra keyiyle ulaşmaktır. Zaten mesela tablo yapısına bakarsan sana bir matrix sunuyor idleri key olarak düşün fieldları value gibi düşün, bir matrixin oluyor, burdan istediğin datayı indexlenmiş bir yapı üzerinden dosyadan daha hızlı alırsın. sadece where id= gibi değil de value'u da sorgulamak gibi. array'de value sorgusu yapmak için phpde jsde ne yapabilirsin alp tarafından 06/May/15 14:05 tarihinde düzenlenmiştir