Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How NoSQL forced the evolution of a scalable relational database

blog.memsql.com

Post reply on HN
Print view View original

21–30 of 211 posts

Re: How NoSQL forced the evolution of a scalable relational database

#21

Post by dragonwriter »

mikekchar wrote: post #8
stephenr wrote: post #3

> NoSQL came into existence because the databases at the time couldn’t handle the scale required. Arguably the first "NoSQL" database was a DIT, generally accessed via the LDAP protocol. OpenLDAP is one of the better known open source instances, but Novell eDirectory was there in the early part of this century, as was MS AD. In the case of Directory Services, it's a completely different approach to both SQL and the c…

There were NoSQL databases well before LDAP was a thing. We called them "Object databases". The idea was that doing object relational mapping was a PITA and wouldn't it be better to store your domain objects directly in the database? (As an aside, in case you are curious, the answer is: No. Generally it's not a good idea) Of course if your data is not relational, you can't do SQL. :-)

> Of course if your data is not relational, you can't do SQL.

The relational model is, as I understand it, fully general, so this literally cannot be the case. There is a problem of “if you do not know the shape of the data in advance” and “if the RDBMSs available to you do not efficiently handle data of the particular shape and access pattern you are using”, but “relational” isn't an inherent property of data, it's a property of a data model, and any data that can be modelled can be modelled relationally. That doesn't mean it is efficiently handled by every, or any, existing RDBMS, though.

Re: How NoSQL forced the evolution of a scalable relational database

#22

Post by keithnz »

I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. While scaling is one of the advantages, I'd be super surprised if many people actually need scaling capabilities ( other than because their design is super inefficient ).

Recently I've been inspired to play around with kicking out as many layers between a relational db and a REST Api, largely because I've been watching https://www.twitch.tv/nybblesio ( who I first came across here on HN on a thread about live coding via twitch streaming ). One of his projects he works on is a SASS product which is largely done in postgresql leveraging https://github.com/PostgREST/postgrest . Seems pretty good, going to be interesting to see how it turns out ( though I haven't seen him work on it lately )

I tend to like SQL Server, ASP.NET Core and found https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018... and I've been playing around with this kind of idea and using a lightweight mapper when needed ( https://github.com/StackExchange/Dapper which the stackoverflow people created )

I gotta say, I kind of like it

One of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database.

The REAL problem SQL wrappers need to solve is that most languages don't have a good interface with SQL. So most often SQL is handled in strings and manipulated with string manipulation and there is no type safe way transitioning data from the DB to a general purpose language.

Microsoft at one stage had Linq to SQL which was quite good..... but they killed it :)

Re: How NoSQL forced the evolution of a scalable relational database

#23

Post by ddorian43 »

siscia wrote: post #19
ddorian43 wrote: post #16

Earlier quoted context omitted.

Something that you can use on production based on what your db advertises as it's advantages (high availability + sharding).

I was asking because I am the creator of RediSQL[1] -- SQL steroids for Redis -- which is a less sophisticated product than MemSQL but still has its own use cases. And maybe for parent was enough, or if not it would be very interesting to know what is missing. [1]: http://redbeardlab.tech/rediSQL/

The same answer applies to your product.

Re: How NoSQL forced the evolution of a scalable relational database

#24

Post by threeseed »

stephenr wrote: post #3

> NoSQL came into existence because the databases at the time couldn’t handle the scale required. Arguably the first "NoSQL" database was a DIT, generally accessed via the LDAP protocol. OpenLDAP is one of the better known open source instances, but Novell eDirectory was there in the early part of this century, as was MS AD. In the case of Directory Services, it's a completely different approach to both SQL and the c…

So the developers at Google (BigTable), Facebook (Cassandra), Yahoo (HBase), Apple (FoundationDB), Redis etc are "lazy" and have drunk "too much Kool-aid".

Because these technologies every day power the most demanding applications on the planet.

Re: How NoSQL forced the evolution of a scalable relational database

#25

Post by siscia »

sqlcook wrote: post #20
siscia wrote: post #14

Earlier quoted context omitted.

What are you looking for in a "community" edition?

EE features without support. I hate to bring up Mongo as example, but something similar...where support, additional software/plugins and cloud hosting are where the $ is made. I did thorough testing of Memsql two years ago but went with Aurora instead. Would love to see how the product evolved since (Spark and Streaming integration was just being rolled out at the time), but something tells me pricing will be a deal…

The point is that is not a convenient business model to just sell support, I can definitely understand why they are trying to sell features.

Re: How NoSQL forced the evolution of a scalable relational database

#26

Post by igl »

icebraining wrote: post #15
nostalgeek wrote: post #5

Well, this is exactly why competition is good, in every domain. That's why PostgreSQL got its column mode and JSON type, because there was a clear use case for performance for the former and schema-less data for the latter. EAV pattern is a plague and I'm glad documents are replacing it.

Postgres has had hstore for schema-less data since 2003.

This is a very blunt statement and overvalues hstore. Keys AND values in hstore are and can only be text strings.

Re: How NoSQL forced the evolution of a scalable relational database

#27

Post by threeseed »

logophobia wrote: post #6
stephenr wrote: post #3

> NoSQL came into existence because the databases at the time couldn’t handle the scale required. Arguably the first "NoSQL" database was a DIT, generally accessed via the LDAP protocol. OpenLDAP is one of the better known open source instances, but Novell eDirectory was there in the early part of this century, as was MS AD. In the case of Directory Services, it's a completely different approach to both SQL and the c…

I would say the the rise of nosql options is driven by the need for scalability by a few large companies that desperately need it, and cargo-culting by developers that don't actually need it, but want to be like google and don't want to take the time to properly learn and optimize sql. There's a genuine need for good scalable options, and with stuff like google spanner, those don't necessarily need to be "eventually…

Not sure what you are talking about here.

There have been scalable and strongly consistent databases since the invention of the concept of NoSQL i.e. HBase and Cassandra (CL=ALL).

And the idea that "learning and optimize SQL" would instantly change people's rationale for using these databases shows you don't understand them much at all. There are many factors that come into play. For example you can't use SQL databases for large scale feature engineering.

Re: How NoSQL forced the evolution of a scalable relational database

#28

Post by MarHoff »

igl wrote: post #26
icebraining wrote: post #15

Earlier quoted context omitted.

Postgres has had hstore for schema-less data since 2003.

This is a very blunt statement and overvalues hstore. Keys AND values in hstore are and can only be text strings.

With arrays and composite type the potential for semi-structured schema was there for decades. The concept just got more mainstream with NoSQL, more easy to maintain and more efficient with indexables type such as JSONB.

Re: How NoSQL forced the evolution of a scalable relational database

#29

Post by siscia »

ddorian43 wrote: post #16
siscia wrote: post #14

Earlier quoted context omitted.

What are you looking for in a "community" edition?

Something that you can use on production based on what your db advertises as it's advantages (high availability + sharding).

EDIT: I couldn't reply directly to it's message, now I can, I just copied my previous comment verbatim below.

Re: How NoSQL forced the evolution of a scalable relational database

#30

Post by siscia »

ddorian43 wrote: post #23
siscia wrote: post #19

Earlier quoted context omitted.

I was asking because I am the creator of RediSQL[1] -- SQL steroids for Redis -- which is a less sophisticated product than MemSQL but still has its own use cases. And maybe for parent was enough, or if not it would be very interesting to know what is missing. [1]: http://redbeardlab.tech/rediSQL/

The same answer applies to your product.

Honestly, I believe that for small workload you can definitely use RediSQL in production, it will happily contain your cache or it will be a great SQL database.

However, I need a way to cut it between people just using the free product and people actually supporting the project, so provide as paying feature something that the big company will require it seemed to me the only way to go.

Unfortunately, I don't have the capital nor the bandwidth to go with fully open source product and selling just support, which I don't believe is anyway a good business model.

If you were in my shoes, you would do something different?

Post reply on HN