Uygulama yalnızca yerel olarak bir şeyler yaparsa, veritabanı sunucusu kullanmak anlamlı mı?

41

Temelde sistemde yerel olarak çalışan bir uygulama yazılımı olan bazı uygulamalar gördüm (bu yüzden ağ üzerinden çok fazla iletişim kurmuyorlar). Bu uygulamalar, verilerini depolamak için veritabanı sunucularına bağlı görünüyor.

Bir uygulama örneği Amarok'tur (Linux'ta popüler bir müzik çalar). Hala bunu yapıp yapmadıklarını bilmiyorum, ama Amarok'un kurulmasının bir MySQL sunucusu kurmanız ve arka planda çalışmasını sağlamak zorunda kaldığı bir zaman olduğunu hatırlıyorum.

Sqlite gibi daha küçük bir gömülü SQL çözümü kullanmak yerine, yerel depolama için bir sunucu kullanmanın avantajı nedir? Genel olarak uygulama yazılımından bahsediyorum, mutlaka amarok değil (bu sadece bir örnekti). Bir veritabanı sunucusunu kullanmanın gömülü veritabanına kıyasla anlamlı olduğu durumlar var mı?

database applications

— 9a3eedi
kaynak

4

Veritabanına sahip olmak çok önemli olabilir. Bir işlem içi veritabanına veya ayrı bir işlem veritabanına sahip olmak, bir uygulama tercihi / detayıdır.

— 9000

2

Onu anlıyorum. Soru, neden yerel uygulamalar için bir işlem içi veritabanı (SQLite gibi) üzerinden ayrı bir işlem veritabanı (mysql sunucusu gibi) seçtiniz hakkında.

— 9a3eedi

29

SQLite ne zaman kullanılacağına veya alternatiflerin ne zaman kullanılmayacağına ilişkin oldukça iyi bir bilgi sunuyor:

https://www.sqlite.org/whentouse.html

Bu özet satırı, benim deneyimimde SQLite kullanım durumunu son derece iyi görüyor:

SQLite, istemci / sunucu veritabanlarıyla rekabet etmiyor. SQLite fopen () ile rekabet eder.

Makale bu noktada genişler. Ayrıca "Bir İstemcinin / Sunucunun RDBMS'nin Daha İyi Çalışabileceği Durumlar" başlıklı bir bölümü vardır. Özetle, onlar:

İstemci / Sunucu Uygulamaları : bir ağ üzerinden birden fazla kullanıcı.
Yüksek hacimli Web Siteleri : ya yoğun yazma ya da paylaşmayı gerektirecek kadar yoğun okuma.
Çok büyük veri kümeleri : bir diskte makul şekilde depolanabilenden daha büyük.
Yüksek Eşzamanlılık : özellikle eşzamanlı yazar.

— Denis de Bernardy
kaynak

@ 9a3eedi: aslında, bu dört nokta arasında, yerel veri depolama ile birlikte tam bir veritabanı sunucusuna sahip bir senaryo tanımlayan hiçbir şey yok (özellikle de ilk ikisi bunun tam tersidir) - bu yüzden bunu neden seçtiğinizi bize bildirir misiniz? cevap, asıl sorunuza uymuyor olsa da? Bu arada, bu cevaba tam da bu sebeple bir önem verdim.

— Doc Brown

@DocBrown: Bir istemci / sunucu kullanmanız gereken özel durumlar RDBMS [cevaba bakınız]; her şey için SQLite iyi çalışıyor. Orada neyin belirsiz olduğundan emin değilim, bu nedenle, gerektiğine inanıyorsanız cevabı düzenlemekten çekinmeyin.

— Denis de Bernardy

Asıl soru, ac / s veritabanının, eğer uygulamanın sadece yerel şeyler yapması halinde (başlıktan alıntı yapması ) veya yerel depolama için bir sunucu kullanması (soru metninden alıntı yapması) için mantıklı olduğu belirli vakalarla ilgiliydi . Yukarıdaki dört senaryo, bunun tam tersi (ilk iki) ya da "olası" senaryolar olarak çok nadiren ya da nadir görülür (ikinci iki). Yani yazdıkların yanlış değil, ama soruya uymuyor.

— Doc Brown

@DocBrown - ve kısa cevap şudur: büyük boyutlu veri setleriyle uğraşmıyorsanız veya eşzamanlı yazmaya gerek duymazsanız, bu hiçbir anlam ifade etmez. (Ya da, bariz sebeplerden dolayı, SQLite'ın sunmadığı bir şeye ihtiyaç duyuyor.) Bu nokta sizin için belirsizse, cevabı düzenlemekten çekinmeyin.

— Denis de Bernardy

Peki, listenin gerçekten tamamlandığını düşünüyorsanız (ve yerel bir senaryo için C / S DB sunucusunun kullanımının bir anlam ifade etmediğini gösteren gizli bir ifade verin), o zaman katılmıyorum ve geliştirebileceğimi sanmıyorum. Bazı açıklamalar ekleyerek cevabınızı.

— Doktor Brown

28

Tek kullanıcılı tek bir sistem için bile, "gerçek" bir veritabanı sunucusu anlamlıdır:

Tanıdık bir dil kullanır ( SQL ). SQLite SQL kullanıyor ancak bazı gömülü veritabanları (örneğin, nesne veritabanı , NoSQL ) SQL kullanmıyor. Bunlar daha az yaygın olduklarından daha yüksek bir öğrenme eğrisine sahip olma eğilimindedir.
SQLite gibi ürünlerin sağlayamayacağı veya en azından tam olarak sağlayamayacağı referans bütünlüğü, kısıtlamaları, tetikleyicileri vs. sağlar.
Gerçek bir çok kullanıcılı, ACID uyumlu ağ veritabanını hedefleyerek , uygulama tek bir kullanıcı / tek iş istasyonu senaryosunda veya aynı kod tabanını kullanan çok kullanıcılı bir barındırılan uygulama olarak çalışma seçeneğine sahiptir .
Kullanıcı standart araçları (örneğin, SQL Developer, MySQL Workbench, SQL Server Management Studio'yu) kullanarak verileri çevrimdışı olarak inceleme, bu araçları kullanarak veri yükleme veya yedekleme, vb. Gibi çeşitli gömülü veritabanları ile bunu yapmak mümkün türleri, insanlar C / S veritabanı dünyasındaki bu araçlara daha aşina olabilir.

Temel dezavantajı, teknik olmayan kullanıcılar (ve hatta birçok teknik kullanıcı için) biraz karmaşık olan veritabanı sunucusu yazılımını kurmaya ve sürdürmeye ihtiyaç duyuyor. Linux gibi işletim sistemleri bunu kolaylaştırıyor: PostgreSQL ve Linux sistemimde çalışan MySQL var. Onlara çok az veya hiç etkileşim olmadan kendilerine bağlı uygulamalar yükledim.

— Doktor Brown
kaynak

9

Aslında (yani Sybase SQL Anywhere) yok tam bir SQL desteği, referans bütünlüğü, ASİT, saklı prosedürler ile bir veritabanı sistemi vardır değil o olabilir gerçi (yerel bir yapılandırmada çalıştırdığınızda bir sunucu kurulum veya bir hizmet olarak bir yükleme gerektirmez çok kullanıcılı bir ortam için kurulum). Bu özelliklere sahip başka bir veritabanı sistemi bilmiyorum, birisi biliniyorsa ilgilenirim.

— Doc Brown

3

@DocBrown IIRC MS SQLServer Compact , dll olarak geldiği için size bunu verir, ancak LocalDB muhtemelen daha iyi bir seçimdir - yönetici hakları gerektirse de bir hizmet olarak kurulum gerektirmez.

— gbjbaanb

5

Dezavantajı geçerliliği tartışmaya eklemek için - cevabında merakla dile getirilen SQLite dışında, bazı SQL dışı veritabanı ve veritabanı benzeri sistemler, örneğin OrientDB, Solr ve diğerleri, gömme desteğine sahiptir .

— mikołak

14

SQLite, referans bütünlüğü (açılması gerekiyor) ve temel kısıtlamalar sunar. Ayrıca, doğru kullanıldığında çoğu sunucudan önemli ölçüde daha hızlıdır. Sunucuya göre en büyük dezavantajı tek yazar olması.

— Jan Hudec

2

@DocBrown: Firebird'ün yerleşik veritabanı, referans bütünlüğü, ACID garantileri, depolanan süreçler ve tetikleyiciler dahil olmak üzere tam SQL desteği sağlar. Katıştırılmış bir veritabanına aynı anda birden çok bağlantıyı desteklemek için kullanılmadı ve bu sınırlamanın hala geçerli olup olmadığından emin değilim, ancak SQL özellik kümesinin tamamı orada.

— Mason Wheeler

21

Ben atalet ile ilgisi olduğunu düşünüyorum.

Amarok 1997’den XMMS’e dayanıyor. Veri tabanı özelliklerinin iyi olması için bir sunucu kullanmanız gerekiyordu, çünkü dosya tabanlı çözümlerden çok daha güçlüydü, hiçbir şekilde iyi veri tabanı özelliklerine sahip değildi.

SQLlite gibi iyi yerel gömülü veritabanlarının yaklaşmakta olan ve popülerliği oldukça yeni bir şey.

— Pieter B
kaynak

Hatırladığım kadarıyla, AmaroK 1 (XMMS tabanlı olabilir) bir veritabanı sunucusuna bağlı değildi. Bu bağımlılık tanıtıldı KDE4 ile salıverilmiş Amarok 2, idi ve zaman onlar instal MySQL beni gerektiren ve arka plan çalışmasını devam ederdi, çok tuhaf bulundu

— 9a3eedi

10

En önemli ayırt edici özellik eşzamanlılıktır .

Kullanıcı için bir örnekte çalışan tek bir uygulamanız varsa, gömülü çözüm (sqlite veya bir nesne deposu olsun) genellikle normaldir.

Ancak, veritabanını aynı anda değiştirmek zorunda olan birden fazla örneğiniz varsa, senkronize etmek için bir sunucunuz olması gerekir. SQLite, bir seferde yalnızca bir defada, tüm veritabanında yazmaya izin verir ve diğer birçok gömülü çözümü de kullanır. Birden fazla uygulamanız bile varsa, yerleşik çözümlerin genellikle izin vermediği daha ayrıntılı bir kısıtlama belirtimine ihtiyaç duyabilirsiniz.

— Jan Hudec
kaynak

5

Diğer cevapların birçoğu bir avantaj olarak eşzamanlılıktan bahseder, ancak db bir sunucu olarak çalıştığından, veritabanı çalışan uygulamanın gereği olmadan görevleri çalıştırabilir. Bu, bakım, yedekleme, başka bir sunucu ile senkronizasyon veya zamanlanmış görevin herhangi biri olabilir.

Uygulamanızın bir istemci / sunucu uygulamasına dönüşebileceğini düşünüyorsanız, daha sonra taşımak yerine, başlangıçtan itibaren bir RDBMS kullanmaya başlamak isteyebilirsiniz.

Verilen örneğin bundan faydalanıp faydalanmadığı hakkında hiçbir fikrim yok.

— JeffO
kaynak

2

Düşük bellek ve işlemci ile gömülü bir sistem çalıştırmıyorsanız, arka planda bir sunucu çalıştırmanın size zarar verdiğini sanmıyorum.

Yerel olarak bir veritabanı sunucusu çalıştırmak iyidir. Veritabanı, verilere erişmek ve bunları işlemek içindir. Ağ erişimi gerekebilir veya gerekmeyebilecek bir artıdır. Bunu yapan bazı mühendislik ve bilimsel araçlar var.

Yerel bir uygulamada veri kullandığınızı varsayalım. Neden bir veritabanı kullanmamalısın? neye karşı olarak?

— cauchy
kaynak

Bir uygulamayı normal kullanıcılara dağıtacak olsaydım (AmaroK gibi bir müzik çaları söylersem), MySQL sunucusunu kurmalarını ve arka planda çalıştırmalarını biraz daha fazla bir sistem gereksinimi olduğunu ve kullanıcıların bir şey olacağını düşünürdüm. gibi değil. Ama sanırım uygulamaya bağlı. Bu, SQLite gibi bir şey kullanmak yerine.

— 9a3eedi

2

Veri özetinize ve genel uygulama alanınıza, erişim yönetimi gereksinimlerinize, veri bakımı için planladığınız yatırıma, gerekli prototiplerin aciliyetine, öğrenme eğrisinde bulunduğunuz yere vb. Bağlıdır.

Diğer uygulamalardan erişimi gerektirmeyen bir uygulamaya sıkı bir şekilde entegre bir veritabanı sağlamak istiyorsanız, gömülü veritabanı adaları oluşturun. SQLite ile Mozilla Firefox Web Depolama uygulaması örnek olarak verilebilir.

Sınırlı verilerle daha da fazla verime ihtiyacınız varsa, bir In-Memory Databas tasarım seçimi tercih edilir.

Öte yandan, aynı veriler üzerinde birden çok sorgu çalıştıran birçok uygulamanız varsa ve performansı optimize etmek için daha iyi veri depolama yapılandırması gerekiyorsa, merkezi bir DBMS gereklidir. Çok büyük miktarda veri gerektirdiğinde ve sorgu yanıtlama süresinin genel olarak kullanıcı deneyimini önemli ölçüde etkileyeceği bilimsel araştırma için kesinlikle tercih edeceğim.

Amarok davasında, o zamanlar gömülü veritabanlarının yolunu seçmeden önce açık kaynaklı DBMS'nin bir seçkisi olduğunu düşünüyorum.

Elinizde belirli bir sistem tanımı varsa, eksilerini ve artılarını ağırlıklandırmak daha kolay olacaktır.

V / r, Umut

— Umut Kahramankaptan
kaynak