May 14, 2013 at 11:13 pm
Comments posted to this topic are about the item The Challenger
May 15, 2013 at 1:42 am
NuoDB used to be NimbusDB. As far as I can tell NuoDB release one was in January this year.
The NewSQL arena seems to have had quite a few products that have come and gone in a very short timespan.
Some of the so-called NewSQL offerings are niche engines for MySQL or offer some form of sharding for MySQL. For some reason MySQL Cluster gets lumped into the NewSQL bucket.
There are some interesting developments out there for the MySQL engines, notably TokuDB with its fractal indexes.
So far the NewSQL DB that seems to crop up most often and appears to have been around the longest is VoltDB. There are lots of positive stories surrounding that particular product as opposed to no stories for the others.
May 15, 2013 at 6:19 am
Steve, I think you "hit the nail on the head" when you said that SQL Server includes a lot of features beyond the database engine. If you're coding to ANSI standards, then moving the actual database code shouldn't be too much of an issue. However, it's all the goodies, that make the whole SQL Server ecosystem, that make SQL Server such a compelling platform to work on.
I've looked at a few other database engines. And they all seemed reasonable. But, then you look at the extra tools, and it's like, "Um... I'll stick to SQL Server." I can do in a few clicks, what will take a good deal of programming to do in some other product. Or, worse yet, can't be done in other products. Yes, the ecosystem is a very compelling argument for staying with SQL Server.
Thanks,
MKE Data Guy
May 15, 2013 at 7:01 am
Postgresql looks awesome. It builds easily from source, and has a nice featureset given the cost. "Redgres" looked to be a pilot project, and given their link leading to a parked domain and the only link provided pointed an "alpha" release. Nobody is going to run production on an alpha version, so obviously we can't judge the popularity of T-SQL compatibility based on what looked to be a pilot experiment from a crew who probably couldn't follow through beyond an initial alpha release.
May 15, 2013 at 7:06 am
Ultimately I think it's easier to stick to as few platforms as possible to allow your staff to build expertise in optimizing their code and configurations for a platform.
It is so true that the development / maintenance costs, reliability, and performance of a database has much more to do with the level of expertise of the staff than the platform itself.
Just the other day, there was a high profile crisis which got escalated to executive management. The runtime of a legacy ETL process increased from a daily average of 2 hours to over 9 hours after the record volume coming from the client doubled. There was some smack talk about SQL Server limitations and prattle that Oracle could handle the data loads more efficiently. So, I was called in to take a look at the process and put out the fire before it got out of hand. I reduced the runtime duration from 9 hours to 17 seconds simply by analyzing the cost of each query and modifying a single line of SQL code.
As for cost of licensing, the only scalability limitation of SQL Server Standard edition is 16 cores. There are many OLTP databases currently running on Enterprise edition that just as well be run under Standard edition for half or 1/3 the cost using per core licensing.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 15, 2013 at 7:30 am
Knowledge Draftsman (5/15/2013)
.... Yes, the ecosystem is a very compelling argument for staying with SQL Server.
Vote +1
May 15, 2013 at 9:40 am
We are currently evaluating NuoDb for a couple of possible uses.
So far the platform seems sound enough but we have only just started.
I can't wait to see how it handles load.
May 15, 2013 at 10:15 am
j.a.c (5/15/2013)
We are currently evaluating NuoDb for a couple of possible uses.So far the platform seems sound enough but we have only just started.
I can't wait to see how it handles load.
If you want to write up your experiences or what you're using it for, we'd love to see an article.
May 16, 2013 at 2:34 pm
Most Pick one, Learn One, and keep one. Others pick a few, learn some about each, and keep what they can afford, and spend lots.
To replace the entire back end? Way too much time, effort, and money!
M.
Not all gray hairs are Dinosaurs!
May 20, 2013 at 5:25 am
Microsoft have made a problem for themselves with the Virtualisation Tax (aka Software Assurance) you have to pay when running SQL Server in the Cloud.
I must stress this is not a technology issue. It is a financial issue. If you compare Enterprise Edition features with (for example) Redshift for a new server, Redshift can give what you need for a fraction of EE costs.
DB staff do have some influence over what technology is used, but so do the bean counters. It is very hard to make a case for a new EE instance in AWS when the competition is Redshift. Add to this that AWS product managers are tasked to reduce product costs twice a year then the business case for SQL Server becomes weaker as time goes by.
SQL Server is a great product, but current licensing costs have pushed it into the high-end price bracket, opening up the same sort of price/feature hole in SQL Server that Microsoft used in the past to attack the other major players.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 20, 2013 at 7:05 am
SQL Server is a great product, but current licensing costs have pushed it into the high-end price bracket, opening up the same sort of price/feature hole in SQL Server that Microsoft used in the past to attack the other major players.
If you have a large number of applications that require SQL Server, then you are commited to the platform, like it or not. And of all the software Microsoft makes, SQL Server is one of the better engineered product lines.
But if you are not a 100% Microsoft shop and a good chunk of your applications are web based and you are not "platform locked", then there's a host of options that need to be weighed.
May 22, 2013 at 3:09 am
I find that the shift from something as core to an IT department such as a RDBMS or OS takes a long time. In general there appears to be the following steps followed:
1) Evaluate alternatives
2) Prototype use of selected alternative(s)
3) Pilot project using selected alternative
4) Pilot system migration to new standard
5) Overtime migrate rest of the systems to the new standard
This often takes over a decade and can be dropped at any stage due to change in management, key technical staff or even the industry.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply