Slashdot Mirror
MEAN Vs. LAMP: Finding the Right Fit For Your Next Project
snydeq writes: LAMP diehards take note: The flexible simplicity of MongoDB, ExpressJS, AngularJS, and Node.js is no joke and could very well be a worthwhile stack for your next programming project, writes InfoWorld's Peter Wayner. "It was only a few years ago that MongoDB, Express.js, AngularJS, and Node.js were raising eyebrows on their own. Now they've grown up and ganged up, and together they're doing serious work, poaching no small number of developers from the vast LAMP camp. But how exactly does this newfangled MEAN thing stack up against LAMP? When is it better to choose the well-tested, mature LAMP over this upstart collection of JavaScript-centric technologies?"
Among the great revelations of relational databases was the JOIN command. With JOIN, we could save disk space by removing repeated fields like city, state, and ZIP code. By storing this frequently accessed and repeated data in separate tables that can be included in future results through a JOIN, we keep our database tidy and our disks slim. But JOINs can be tricky for some and hard on RAM, and though it's still a good idea to isolate and access data in separate tables through JOINs, there's not as much need to save disk space now that disk drives are measured in multiple terabytes. The space is so cheap that some database designers end up denormalizing their data because the JOINs are too slow.
This is just so wrong. If you store, let's say, city/state/zip redundantly, then you run the risk of having the copies, that should be kept synchronized, diverge. This is especially true in the absence of all-or-none transactions. And not to mention the fact that having to update the "same" datum in multiple places is going to affect performance.
I know SQL pretty well. I agree with you it handles most stuff. That doesn't mean it handles everything.
SQL engines are often slower.
SQL engines have problems with massive parallelism (i.e often at around 12 CPUs you stop gaining much at all by adding addition CPU).
SQL engines have problems with complex in document (i.e. in blob) searches
etc...
Not only because stuff like this, https://aphyr.com/posts/322-ca... , but also because MongoDB performance actually isn't that great. I do care about my data, and PostgreSQL is actually faster in some scenarios (eg. if you actually know what you're doing), so thanks, I'll pass. And Apache HTTPD? Who's still using that on new projects?
JavaScript in its current form will never have a place larger than simple website scripting in my production environment -- it's unmaintainable in anything beyond small doses and is something we work with because there's literally no other option, not because we want to. TypeScript makes things better, but being better than JavaScript really isn't that tough. It's still not as good as -- and doesn't provide benefits instead of -- existing common backend languages like Java and C#.
To me, node.js perfectly represents the age of programming we're in: people are doing things because they can, not because they should. Things that would have been just-for-fun geeky side projects 10 years ago are now somehow making their way into legitimate business-critical projects.
The last few years in this case is more like the last decade. Before JSON, there were (and are) XML-typed columns, and any decent RDBMS will let you use XQuery or similar to query on them directly within your SQL query (and will use special indices to optimize such queries). SQL/XML spec, that standardizes this, was published in 2003. Oracle shipped preliminary support of the then-draft spec in 2002; Microsoft shipped it in SQL Server 2005 in, well, 2005; and Postgres shipped it in 8.3 in 2008.
There is exactly a zero percentage chance that I will ever use MongoDB in another project. On the surface it was great. I evangelized my friends about it and the whole NoSQL thing. But as time went by I realized that it wasn't made for people to use. Almost nothing was intuitive. For each new feature that I wanted I had to look up a tutorial and generally found a list of gotchas. If you design your project around MongoDB then it will work. But if you try to wrap MongoDB around your project then you are completely screwed.
Basically MongoDB halved the initial quarter of data storage design and programming. But as the project progressed the time spent screwing with Mongo went up exponentially until the project was shoved out the door and primary feature in version 2 was the complete removal of MongoDB.
I could make a mile long list of places the project stumbled. But a few key ones would be that there are no good data management tools for accessing a MongoDB. The second was that huge schema screwups were way too easy. It was very hard for programmers to get a mile high overview of how data being stored was being structured. That is a data layout was easy but putting the results into your head was really hard.
I am finding other NoSQL approaches are far superior. Things such as use of JSON, memcaches, MariaDB (or the excellent PostgreSQL) working together allows the project to dictate how things function instead of Mongo very quickly shaping the project architecture because of its marked strengths and weaknesses.
Redis is the environment presently being explored for version 4 and so far it is looking very interesting. But I am not joking when I say that at this point I would use access on windows as my backend datastore before I would use MongoDB.
Than engines designed for massive parallelism in dealing with workloads which can be effectually processed in parallel.
Generally NoSQL engines use schema on read techniques not schema on write. The table structure comes during the read. To get some sort of fair comparison something like a typical star schema with a much too large fact table (think billions or trillions of rows) and a half dozen dimension tables.
Or if you really want to make it worse. The same query where the table is getting 1m writes / second and you want an accurate stream.
Because SQL by its nature operates on the table not the individual rows. Older database technologies that were row oriented like what you see on a mainframe on in SaS work better when the ratio of table size to computation speed is low. Today because disk storage size per dollar has gone up so fast, we disk we face many of the same problems systems in the 1980s faced with tape.
And the next question is pretty much all of them. The big data SQL engines have the least problems though and via. their execution plans turning into map-reduces might present a viable long term solution.
Assume I don't know anything. Oracle, which has the best engine and SQL people on the planet has a guide for hybridization to handle things their engine can't handle well. IBM which probably comes in second and invented the relational database produces their own Hadoop / R to handle queries that DB2 (which is BTW far better than Oracle at stream) can't handle. Teradata's engine which was originally written specifically for larger amounts of data for a decade has had specific features of another subsystem to do enhanced big data, they also have guides for hybridization for things even their enhanced engine can't handle And Microsoft which writes the 3rd most popular engine has spent many millions on hybridization strategies. Enterprise DB (postgres) fully supports the IBM strategy.
I don't know anyone in the space who does agree with the /. "SQL can do everything" attitude.
The article was ridiculous I said as much in another response. However the comment I was responding to went much too far in the other direction. As for performance tuning -- performance tuning is designed to avoid full table scans and expensive joins. To goal of many hybridization strategies is to take a raw data flow and convert it into a relational ETL using a big data engine which can take advantage of indexing and a better execution plan. It doesn't do much good when the initial goal is to do a full table scan.
Meteor ( https://www.meteor.com/ ) is a javascript framework that runs on top of Nodejs and it is GREAT. It is a full stack solution, it has a view engine (Blaze templating language, based on handlebars), a server (Nodejs) and a database (MongoDB) all bundled up and it just works out of the box, no configuration required. From the meteor website:
"Really, you'd like to use a combination of packages that have been not just tested individually, but tested together, since so much of the complexity in a large software project comes not from its individual pieces but from how they're integrated. Rather than leaving your package system to select the "best" combination of package versions, which could change every day and could be a totally new combination that nobody else has ever tried, you'd like to use a set of packages that has been comprehensively tested by professional release engineers that really know the platform.
That's what the Meteor Distribution provides. Similar to a Redhat or Ubuntu distribution, the Meteor Distribution is a set of package versions that have been tested and recommended for use together."
And that is just one of the great features that Meteor provides. Another great feature of Meteor is that your Javascript code runs both on the server and on the client _at the same time_. Whatever action you make that triggers a state change (change in the database) will run both on the client and on the server, the client has something called MiniMongo that caches the result from the server database and the changes happen without a roundtrip to the server. If the server state is not consistent with the client state Meteor takes care of synchronizing everything. So the application looks like is running locally there is no lag at all.
This drastically reduce the code necessary for example, you don't write form validation code twice, you write it once and show a popup message on the client and throw an exception on the server if something is wrong. Really everything in Meteor works great, there is a really good automatic deploy system (it even deploys to phonegap, also I believe you can deploy your mobile apps to app stores automatically), the API is really small, the meteor packages work great (check out the Velocity testing framework, it is awesome!) and so on
There is one big caveat though, you can't migrate parts of your existing application to Meteor, the only real optional part of Meteor is the View layer, you can discard Blaze and run your own solution. I have had a great time using React with Meteor for example.
You are correct, I've never worked for Microsoft I don't even sell much Microsoft. Mostly when I'm dealing with SQLServer datasets they have been no problem for RDBMS. My company has helped do connector work for Azure on Hadoop / SQLServer mixtures.
I suspect the reason AC thought I worked for Microsoft was I thought the Windows 8 (and early new interface for Office) migration program (i.e shift the x86 ecosystem) that Balmer / Office group was pushing made a lot of sense and defended it.
Oracle is excellent. Oracle has problems with massive parallelism though. The Oracle engine works well at 10 CPUs handling versatile workloads. It doesn't at 1000 CPUs focusing on one big table scan for one query.
If you aren't using relational you better be using old fashioned block type strategies (i.e. full table writes like you do in COBOL) or not be doing transaction processing at all. That's one of the things you are giving up when you go non-relational. Data changes become much trickier.
But that's not a problem for most NoSQL where you just write the data out, process it for X time and changes are handled via appends if at all. A good relational analogy to the append structure is how RDBMS handle materialized views and data changes.