The Young DBA

After 2005 applications & user requirements started growing rapidly, Hardware and software developed, the advent of Single Page Applications and modern mobile/web apps that we know today needed some kind of data interchange to function seamlessly. To fulfill user requirement technology started shifting into  new language-independent data interchange format that time JSON came into the Picture. JSON gained rapid popularity because it makes transferring data very easy. It’s also lightweight and easy to read and understand. There are few other reasons that JSON make buzzword after 2005. Flexibility for rapid application development requirement APIs (application programming interfaces) Modern Web & Mobile Applications. Need of faster data travelling on various kind of devices. Big Data and variety in data.

Hi Friend, This is the time is your most important time in some productivity. Where the world is suffering from Pandemic of Corona disease (Covid-19). Everyone is under restrained in their home like jail. Govt of India told to stay in home for 21 days. So I decided to share my long pending post in a series. One of my favourite articile I wrote one year back, I got chance to share. I will share this as a series. Here are some topics related to my current Article  " Is it time to revisit PostgreSQL and MySQL with JSON support " . JSON stands for JavaScript Object Notation, and was first formalized by Douglas Crockford. JSON is a data format interchange - method of storing and transferring data. Mostly its uses such as data conversion (JSON to SQL) and exporting data from proprietary web apps or mobile apps. XML was a big buzzword in the early 2000’s, JSON become the buzzword in later few years.  Why JSON came into picture. What are the impacts JSON bring in database t

The database developers/DBAs go through the task of database migration very often in various projects. Most of the times, such tasks have source and destination using the same technology, for example, MS SQL Server to MS SQL Server or MySQL to MySQL, etc. But, in some challenging projects, we encounter some situations in which, the source and destination technologies differ, leaving us in a mess, for example, MySQL to MongoDB, etc. Even this situation can be handled, where we have to migrate from structured to non-structured database technology. But, when it comes to move data from non-structured to structured technology, it becomes a tedious task, for example, MongoDB to MySQL.  As a database developer, I was working on one such project where I was required to migrate data from MongoDB to MySQL. I tried the following steps at the initial level for connecting the source (MongoDB) to destination (MySQL) using Python Requirements : 1. Python 2.7 2. MongoDB 3.2 3. MySQL 5.7 4. My

Avro schema generally used to define the data schema for a record's value. This schema describes the fields allowed in the value, along with their data types. We can apply a schema to the value portion of an Oracle NoSQL Database record using Avro bindings. These bindings are used to serialize values before writing them, and to deserialize values after reading them. The usage of these bindings requires our applications to use the Avro data format, which means that each stored value is associated with a schema. The use of Avro schemas allows serialized values to be stored in a very space-efficient binary format. Each value is stored without any metadata other than a small internal schema identifier, between 1 and 4 bytes in size. One such reference is stored per key-value pair. In this way, the serialized Avro data format is always associated with the schema used to serialize it, with minimal overhead. This association is made transparently to the application, and the internal sche

Difference between key-value stores and key-value pairs or Difference between  Key-value stores  and document db or Difference between Redias and mongoDb .   Key Values always Conf us ed me that's why i decided to share my some short of experience , In NoSQL Databases KV Pair and KV Stores are different. Event they are related to different database vendors too. Key-Value stores ; store keys value pairs  in buckets, exactly like a hash table data structure; where each key must be unique.  They are extremely fast for writing, and extremely fast for reading and updating. if you have the key.  They are slow on multiple updates and if you have to query the entire store.  You see Key-value stores used a lot as caching stores because of their fast reads. eg: Redis, Riak, memcached, Azure's tablestore, etc Document Stores ; store data in "documents", typically XML or JSON documents. They're typically schema-less, so each document can contain any data that you want

Design your Database schema in according to user requirement . Optimize your schema for most frequent use case. Combine objects into one documents if you will use them together, otherwise separate them. Duplicate the data because disk space is cheaper than computing time . Basically avoid joins however do while writing, not during reads. Don't insert mixed data-type values into one common fields, it can degrade performance. Do complex aggregation in schema. Do Capped Collection for fast writing on collection. Use Natural/default Order to read collection. Create index in Background . (offline). Avoid not in and not equal to operation . $ne and $nin .