What does being schema-less mean for a NoSQL Database?

Schemaless is a term that is currently floating around in the NoSql world.

What does this mean ?

I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?

Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.

– amirouche
Jun 26 '18 at 21:13

add a comment |

Schemaless is a term that is currently floating around in the NoSql world.

What does this mean ?

I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?

Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.

– amirouche
Jun 26 '18 at 21:13

add a comment |

Schemaless is a term that is currently floating around in the NoSql world.

What does this mean ?

I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?

Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

Schemaless is a term that is currently floating around in the NoSql world.

What does this mean ?

I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?

Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?

nosql schema

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

asked Mar 23 '13 at 16:33

ashutosh raina

4,69793478

"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.

– amirouche
Jun 26 '18 at 21:13

add a comment |

"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.

– amirouche
Jun 26 '18 at 21:13

"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.

– amirouche
Jun 26 '18 at 21:13

add a comment |

2 Answers
2

active

oldest

votes

Schema-less is a bit of a misnomer, it's better to think of it as:

SQL = Schema enforced by a RDBMS on Write

NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)

So while a supposed Schema-less NoSQL data-store will in theory allow you to store any data you like (typically key value pairs, in a document) without prior knowledge of the keys, or data types, it will be pointless unless you have some mechanism to retrieve and use the data. So essentially the schema is partially moved from the RDBMS into the application code. I say partially as you'll have added Indexes to document collections and or partitioned the data for performance, so the NoSQL DBMS will have a partial schema defined locally, and possibly enforced via Unique constraints.

As to adding additional attributes to a document/object in the store. Depending on how much padding is around the document (un-used space), in it's physical data block, adding a few more key value pairs to the documents may result in the document having to be physically moved to a larger contiguous block of storage, and the associated indexes re-built. If you plan to use the new keys in a frequently utilised query then you'll be wanting to also add a suitable new index, which will obviously require some physical storage, take a while to initially build and possibly lead you to ask the sysadmin to allocate more memory to the DBMS, to allow the new index(s) to be cached.

edited Mar 23 '13 at 18:35

answered Mar 23 '13 at 16:58

arober11

1,5841225

Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?

– ashutosh raina
Mar 23 '13 at 17:49

2

Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.

– arober11
Mar 23 '13 at 18:36

So we need to account for possible increase in document size before hand ?

– ashutosh raina
Mar 23 '13 at 19:06

If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.

– arober11
Mar 23 '13 at 19:57

@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless

– hershey92
Aug 2 '13 at 16:22

|
show 2 more comments

A bit late in the day but while searching on the topic again I found this article

http://tech.pro/tutorial/1189/basics-of-ravendb-nosql

Refer to section 3 in the article, I will quote it again for ease.

Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.

This seems to be the logical answer for RavenDB.

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f15589184%2fwhat-does-being-schema-less-mean-for-a-nosql-database%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

Schema-less is a bit of a misnomer, it's better to think of it as:

SQL = Schema enforced by a RDBMS on Write

NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)

edited Mar 23 '13 at 18:35

answered Mar 23 '13 at 16:58

arober11

1,5841225

Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?

– ashutosh raina
Mar 23 '13 at 17:49

2

Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.

– arober11
Mar 23 '13 at 18:36

So we need to account for possible increase in document size before hand ?

– ashutosh raina
Mar 23 '13 at 19:06

If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.

– arober11
Mar 23 '13 at 19:57

@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless

– hershey92
Aug 2 '13 at 16:22

|
show 2 more comments

Schema-less is a bit of a misnomer, it's better to think of it as:

SQL = Schema enforced by a RDBMS on Write

NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)

edited Mar 23 '13 at 18:35

answered Mar 23 '13 at 16:58

arober11

1,5841225

Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?

– ashutosh raina
Mar 23 '13 at 17:49

2

Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.

– arober11
Mar 23 '13 at 18:36

So we need to account for possible increase in document size before hand ?

– ashutosh raina
Mar 23 '13 at 19:06

If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.

– arober11
Mar 23 '13 at 19:57

@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless

– hershey92
Aug 2 '13 at 16:22

|
show 2 more comments

Schema-less is a bit of a misnomer, it's better to think of it as:

SQL = Schema enforced by a RDBMS on Write

NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)

edited Mar 23 '13 at 18:35

answered Mar 23 '13 at 16:58

arober11

1,5841225

Schema-less is a bit of a misnomer, it's better to think of it as:

SQL = Schema enforced by a RDBMS on Write

NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)

edited Mar 23 '13 at 18:35

answered Mar 23 '13 at 16:58

arober11

1,5841225

edited Mar 23 '13 at 18:35

answered Mar 23 '13 at 16:58

arober11

1,5841225

answered Mar 23 '13 at 16:58

arober11

1,5841225

answered Mar 23 '13 at 16:58

arober11

1,5841225

Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?

– ashutosh raina
Mar 23 '13 at 17:49

2

Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.

– arober11
Mar 23 '13 at 18:36

So we need to account for possible increase in document size before hand ?

– ashutosh raina
Mar 23 '13 at 19:06

If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.

– arober11
Mar 23 '13 at 19:57

@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless

– hershey92
Aug 2 '13 at 16:22

|
show 2 more comments

Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?

– ashutosh raina
Mar 23 '13 at 17:49

2

Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.

– arober11
Mar 23 '13 at 18:36

So we need to account for possible increase in document size before hand ?

– ashutosh raina
Mar 23 '13 at 19:06

If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.

– arober11
Mar 23 '13 at 19:57

@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless

– hershey92
Aug 2 '13 at 16:22

Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?

– ashutosh raina
Mar 23 '13 at 17:49

Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.

– arober11
Mar 23 '13 at 18:36

So we need to account for possible increase in document size before hand ?

– ashutosh raina
Mar 23 '13 at 19:06

If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.

– arober11
Mar 23 '13 at 19:57

@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless

– hershey92
Aug 2 '13 at 16:22

|
show 2 more comments

A bit late in the day but while searching on the topic again I found this article

http://tech.pro/tutorial/1189/basics-of-ravendb-nosql

Refer to section 3 in the article, I will quote it again for ease.

Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.

This seems to be the logical answer for RavenDB.

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

add a comment |

A bit late in the day but while searching on the topic again I found this article

http://tech.pro/tutorial/1189/basics-of-ravendb-nosql

Refer to section 3 in the article, I will quote it again for ease.

Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.

This seems to be the logical answer for RavenDB.

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

add a comment |

A bit late in the day but while searching on the topic again I found this article

http://tech.pro/tutorial/1189/basics-of-ravendb-nosql

Refer to section 3 in the article, I will quote it again for ease.

Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.

This seems to be the logical answer for RavenDB.

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

A bit late in the day but while searching on the topic again I found this article

http://tech.pro/tutorial/1189/basics-of-ravendb-nosql

Refer to section 3 in the article, I will quote it again for ease.

Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.

This seems to be the logical answer for RavenDB.

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

answered Apr 4 '13 at 18:49

ashutosh raina

4,69793478

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu