In recent times as the need for large, organized and especially reliable data stores has increased, so has the need for easy management of these resources. It is inevitable that every business seeks databases that can hold their data and provide proper management tools to manage it. The job for the Database Administrators is already challenging, and with the switch from single node systems (residing on one server/machine) to clustered systems (residing on multiple machines/servers), managing resources can be very stressful. Now when you think about managing clustered database systems, you have to manage the databases, their respective properties, and also the clusters on which these databases reside.
NosDB solves this headache with “NosDB Management Studio”, allowing you to operate multiple machines from a single location, easily and efficiently. Before we proceed to how NosDB solves your problems let us briefly examine what NosDB is. NosDB is a clustered database system, which insures reliability by accommodating large amounts of data in databases, on different servers. A cluster in NosDB is comprised of shards on which the data is distributed on the basis of configurable distribution strategies. Each shard may have one or more replica nodes which replicate data of the shard. This works just like an internal fault tolerant backup system, so that you don’t have to worry about data losses. Explore more about clusters and their concepts with NosDB Conceptual Guide.
In this ever-evolving world, advancement in technology is accelerating at an extremely fast pace. Traditional databases have become far too slow, presenting serious bottlenecks, both in terms of speed and storage capacity. Therefore, the advent of a much needed replacement, the introduction of NoSQL, was seen as a life saver by many serious players out there.
Delving into this market, Alachisoft has also introduced its very own NoSQL document database for .NET, NosDB, released under the Apache 2.0 license. NosDB is a key-value store which takes string based values as keys and stores objects in the form of JSON against them. Being fast and extremely scalable, it makes for a good substitute for those wanting to shift from the legacy database systems. You can get started with the product following these five quick steps:
A database, as you may already know, is a collection of data stored in an organized way allowing you to retrieve it efficiently. While every typical .NET enterprise application incorporates a database, the data it stores is also usually accompanied by some files e.g. pictures, videos, documents etc.
In .NET applications, these files are treated as binary data and the best way to store them would also be in a database. In order to maintain relevance between the data and the files, traditionally you have two options:
- Either store the binary data in the related JSON document. For example, a customer object containing its picture
- Or store the files in your file-system (hard-disk) and keep links pointing to those files in your JSON document. For example, store customer object in the database and the picture separately in your hard-disk. Store the link to this picture in your customer object as well.
NosDB is a schema-less, scalable NoSQL database solution for .NET that accommodates immense volumes of unstructured data. Because NosDB provides availability and fault tolerance through sharding and distribution strategies, it concurrently generates a need to monitor the impact of operations on your system.
Hence, once NosDB has been deployed and databases are created, IT administrators need to continuously monitor the environment to diagnose and prevent any problems from aggravating in the future, like network choking, peaks in resource utilization and unauthorized access attempts. In addition to these problems, you will want to monitor NosDB to assess general status of load, node operation and cluster health.
Many companies value data more than hard cash. The reason is simple; Data generates business. With this much importance given to data, it should be obvious that database security should also be of utmost importance. Database security means involving multiple measures to protect your data from illegal access or worse; data theft. Those multiple measures include;
- Data Encryption
- Transport level encryption
- And more …
Publisher Subscriber design patterns are an invaluable tool for building enterprise grade .NET/C# applications. Among them you will be very familiar with the Publish-Subscribe pattern also known as Pub/Sub. Just to refresh your memory, Pub/Sub is basically a messaging pattern where the senders of messages (publisher) do not have any knowledge about the intended recipients as in, which applications are the receivers or how many of them are there. Also, the publishing and listening application do not interact with each other directly but instead depend on a common medium, without knowledge of the producer or consumers presence.
Businesses today are developing high traffic ASP.NET web applications that serve tens of thousands of concurrent users. To handle this type of load, multiple application servers are deployed in a load balanced environment. In such a highly concurrent environment, multiple users often try to access and modify the same data and trigger a race condition. A race condition is when two or more users try to access and change the same shared data at the same time but end up doing it in the wrong order. This leads to high risk of loosing data integrity and consistency. This is where distributed lock mechanism comes in very handy to achieve data consistency.
ASP.NET web applications, .NET web services applications, and other .NET server applications need to handle extreme transaction loads without slowing down. And, although their application tier scales linearly, the data storage and database tier does not scale and therefore becomes a bottleneck. As a result, the entire application cannot scale.
Originally, simple in-memory distributed key-value stores like Memcached and later Redis were introduced on Unix/Linux platforms to help resolve this scalability problem. They quickly became quite popular mainly because they provided linear scalability just like the application tiers and removed the database bottleneck.
A Look Back and Our Future Vision
With enthusiasm and stars in our eyes, NCache was launched in July 2005. And wow have we all come a long way since then! We’ve grown up with the .NET community and its adoption of caching solutions. Back then, caching was pretty new for .NET. I remember we wrote articles, created slideware, went to shows, meetups and prospects everywhere educating developers and managers about the benefits of caching, how to architect it and what it can do for the enterprise. At the time, .NET itself was not used as much in high transaction, high traffic applications as it is today. But it took hold.
Update: Microsoft has extended the AppFabric support to April 11th 2017. The extension is only applicable for AppFabric 1.1 and not for 1.0. For more information check out their blog post.
April 2nd 2016 (April 11th 2017) is proving to be an important date for Alachisoft’s product NCache. This is the date when Microsoft ends AppFabric support – essentially withdrawing the product from the market. See details on Microsoft AppFabric 1.1 for Windows Server Ends Support 4/2/2016
AppFabric was Microsoft’s answer to .NET industry’s need for an in-memory distributed cache to provide performance and scalability boost for .NET server applications. But, first it was late to the party with AppFabric 1.0 released in June 2010 (five years after NCache). And, second, it struggled to provide the features and functionalities considered de rigueur for in-memory distributed caches. Eventually, Microsoft decided to pull the plug on a product that essentially provided less features than other .NET caching solutions like NCache.
Read AppFabric vs NCache comparison and see for yourself how much AppFabric lacked in features and capabilities.