C# sunucuya sürekli veri kaydetme

Arkadaşlar Merhaba,
Benim şöyle bir sorum var ethernete bağlı bir cihazım var bu cihaz durmadan veri gönderiyor. Ben bu veriyi c# ile durmadan okutup (milisaniye bazında durmadan yazacak) sunucudaki mssql e yazsam sıkıntı çıkarır mı? Alternatif şekilde neler önerebilirsiniz.

Düzenli şekilde kaydedip veri kaydetme sınırını aşmazsan sorun yaratmaz.
Düzensiz veri sql bağlantısını yavaşlatır.

Milisaniye demişsiniz. Gelen verinin büyüklüğü nedir?

eger iliskisel bir db ye ihtiyac duymuyorsan ve karmasik sorgular yazmayayacaksan rdbms lere bulasmana gerek yok. NoSQL cözümlerden bir tanesiyle gayet hizli ve güvenli bir sekilde halledebilirsin. Tavsiyem MongoDB ve Cassandra ya bakman, bu ikisini hiz yönünden karsilastir. mongodb json tabanli tutar verileri, gayet hizli yazma ve okuma özelligi var (text indexes özelligi ile cidden hizli sorgular yapabilirsin https://docs.mongodb.com/manual/core/index-text/ ). Database bilgin ne derece ama noSQL, rdbms gibi ACID prensibiyle degil de CAP ile calisir. Genellikle herhangi bir structer u olmayan ya da semi-structured datalar icin kullanilir daaha cok. Bir kac cesit bulabilirsin, graph tabanli, key-value tabanli, column tabanli (cassandra bu grupta), document tabanli (mongodb bu grupta)

veri fazla olmayacak büyüklükle ilgili bir sıkıntı çıkarmaz ama durmadan sql e bağlanıp yazması sql i patlatırmı diye bi düşünüyorum.



Teşekkürler sql bilgim var. Söylediklerinizi inceleyip bi bakacağım.

asenkron uygulama yazabilirsin..
https://msdn.microsoft.com/en-us/lib...v=vs.113).aspx

entity framework un ne kadar yavas oldugundan sanirim haberin yok.. Ado.Net bile EF nin yaninda cok daha hizli. EF nin amaci hiz degil kolayliktir. Arkadasin aradigi daha cok hiz. O yüzden asenkron olarak islem yapmanin pek bir getirisi olmayacak, zaten sürekli baglanti acik olacagi icin de bu sisteme iliskisel veritabanlari uygun degildir. O yüzden noSql cözümü önerdim ki en ideali ve uygunu o. Ama illa iliskisel db ile yapmak istiyorsa o zaman EF yerine, dapper kullanmasi daha mantikli olur. Ama sahsi tavsiyem kesinlikle noSQL.

MSSQL üzerinden gitmek istiyor o yüzden önerdim.Entity Framework Core çok daha hızlı onuda deneyebilir.
Evet haberim var .Şöyle var Özel bir uygulamaya bağlı olarak Telegram Bot çalışıyor hızı da gayet tatminkar.

En kötü ihtimalle test edip tecrübe eder.Olmadı başka bir ORM tool kullanabilir.
Entity Framework tercihi hız konusunda ne kadar hızlı olması istediğine ve veriye bağlı.
Güncel testlere bakacak olursak bu konuda da Dapper önde

hocam ne diyorsun anlamiyorum. Adam zaten yazmis milisaniye bazinda islem olacak, sen de entity framework ile asenkron uygulama ilgili bir link vermissin. Hangi acidan bakarsan bak önerin zaten bir cok acidan mantiksiz. Ado.Net iclerinden en hizlisi olmasina ragmen (dapper baya yakin ya da esit) yine de bu tarz bir sistem icin uygun degil. Belki sürekli acik bir baglanti üzerinden gidilir ama bunlarin hic birine gerek yok. Azicik akli ve bilgisi olan adam zaten böyle bir sistem icin rdbms kullanmaz. Kullanirim diyen adamin zaten hem db hem yazilim bilgisi olduguna inanmam.
EF core demissin, core sisteminin amaci platform bagimsiz isler yapmak icin ancak core sistemlerinde bir cok özellik eksik. Hic inceledin mi bilmiyorum ama ben asp.net 1.0 core dan itibaren biliyorum ve bunla ilgili microsoft un verdigi seminerlere de katildim. EF core un eksik oldugu noktalar var.
Sonuc olarak arkadasin anlattigi sisteme en uygun cözüm noSQL dir. RDBMS kullanmak istiyorsa onun bilecegi is, muhtemelen uygulama bir yerden sonra tikanir. Cünkü milisaniye bazinda araliksiz veri olayini hele kendi local bilgisayarinda yapacaksa kaldiracagini düsünmüyorum. oracle dan tut da , ms sql e kadar bunlar büyük ve komplike isler icin tasarlanmistir. Ancak büyük firmalara bakarsan, twitter, google, facebook vs hepsi bir rdbms in yaninda bir ya da daha fazla nosql cözümü kullanir. Hatta kendi cözümlerini bile olustururlar. Ornek olarak, facebook icin cassandra, google icin bigtable. Cünkü bu sistemler icin hiz önemlidir. Twitter, anlik istenen twitterlarini arsiv amacli haric bir rdbms de saklamaz. Onun yerine daha hizli yazip okuyacagi noSQL sistemlerinde saklar. Keza bu mantik tüm hiz gerektiren ve karmasik/iliskisel islerde gecerlidir eger isi gercekten biliyorlarsa.
Türkiye'deki yazilimcilarin ve sirketlerin bilgileri kit oldugu icin bir cogunun olan bitenden bile haberi yok. Oysa bahsettigim cözümler irili ufakli her yerde kullanilir avrupa'da. ACID sistemi (rdbms in temel aldigi sistem) bir cok ihtiyaci karsilamadigi icin CAP (nosql in temel algidi sistem) gelistirilmistir. CAP teorimine göre CAP in her bir modulunun 2 si kullanilir ve tüm nosql cözümleri bu modüllere göre belirlenir. Yani CA yi kullanan nosql cözümleri var, CP yi kullanan var ve yine AP yi kullanan var. Bu nosql cözümleri de birbirinden tamamen farklidir. Bazilarinda birden fazla node icin herhangi bir farklilik olusmasin istenirken bazilarinda nodelarda farkli veriler olabilir ama veri kaybi yasanmasin der. Bazilari her an veriye erisebileyim der herhangi bir noddan bazilari baska bir beklenti icindedir. Iste bunlar icin farkli cözümler var. Yani mongodb de bir nosql sistemi, cassandra da ama birisi CP digeri AP ye göre calisir.
Suraya bir resim birakayim biraz daha anlasilmasi icin. Bundan sonra zaten haala olayin ne oldugunu anlamayan adam varsa, diledigi gibi yasasin. Ortalik sahte uzmanlardan gecilmiyor.




not: resimde CA ile gösterilen yerde mysql görebilirsiniz. mysql bir nosql cözümü degil rdbms dir. Ancak nosql kullanan yapisi mevcut https://www.mysql.com/products/cluster/nosql.html