it seems that
http://www.i-programmer.info/news/81...nd-oracle.html

Guardian is switching from Oracle to MongoDB and the following
presentation is most revealing on the reasons:

http://qconlondon.com/dl/qcon-london...ardianCoUk.pdf

Since I hadn't been following the VectorWise project closely,I
couldn't help but wonder whether VectorWise could fit into this
picture and be used instead of Oracle, or is it solely targeted for
business intelligence? (although Guardian's moving away from the
relational structure model to JSON looks like very special
requirements)

Thanks for posting it.

I think it makes me think that often a move to a new technology is a
good catalyst for a restructuring when things start getting difficullt
to modify. I'm not sure though that moving to MongoDB is really the
saviour rather than a plain old-fashioned refactoring exercise to
redesign the business and domain model.

I't looks like SQL queries are replaced by other forms of queries and
really it comes down to the speed of the query engine in the context of
this application. Who is to say that another architecture using
uderlying SQL and a cache would work just as well.

Anyway, anything moving someone away from Oracle is a good thing,
whatever the reason, bogus or not.

Good read, though.



On 16/04/2011 10:34, nikosv wrote:

nikosv wrote:

I've never understood why CMS systems wanted to use SQL databases in the
first place. None of the SQL products that were available 10-15
years ago were particularly suitable. Even the ones that were
halfway-decent required more self-discipline than the average
programmer can muster. The situation with today's SQL DBMSs is not
much better. They remain best suited to transactional processing and
analytics, and anyone doing anything else would be stupid not to be
considering using something else. That *is* an indictment of SQL DBMSs.

There is no reason I can think of why a relational database wouldn't be
a good choice if there were a suitable implementation. But relational
DBMSs don't exist, so we'll never know if that conjecture holds water.

But to get to the point, no, I don't think VectorWise solves the SQL
problem, which is what the Guardian is really trying to solve.
VectorWise gives you fast searching, fast bulk joining, fast reduction
and dense compression.

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Register at http://www.regonline.co.uk/ukiua2011

On 18/04/2011 10:55, Roy Hann wrote:
I really don't understand what you are trying to say. What is it about
SQL databases that is unsuitable for use with a CMS and what are the
alternatives that these undisciplined CMS programmers should have been
using?

I'd really like to know what the "something else" candidates are.

I must say I didn't really "get" what this SQL problem is. My view was
that their existing setup had become unwieldy and like any project
review might do, an alternative technology provided the performance they
needed together with a good query engine.

All technology migrations provide the relief of a clean sheet to work
with and, cynic that I often am, this is easier to champion than an
extensive revision of the technology already in place. I don't think the
slides really mention the economics of the new infrastructure versus old.

Whose to say that an overhaul using an SQL database suited to their new
way of thinking/working would have been just as good? They've got a
master database that is updated then pushed out as updates onto
replicated databases on multiple servers.

Couldn't an SQL database with a query cache work just as well?

...sounds ideal when you are trying to pull together page content
dynamically. Why wouldn't that be good for a CMS based application.

Roy, seriously, I'd be interested to know more of your thoughts on the
guardian project.

be a winner at the same time; performance, scaling, hardware re-
use,act on very complex queries as to combine information/data mining
which might be present in a newspaper system

On Apr 20, 2011, at 11:48 PM, James K. Lowden wrote:

[good stuff clipped]

Don't hesitate. We need to talk about this stuff. Ingres is too easy
to manage and we don't have other problems to talk about like other
vendor groups do.

[more stuff clipped]

So true.

Apparently, you've never lent your car to my youngest daughter.

;-)

Cheers,

Michael Leo
Kettle River Consulting

I'm just glad that I've started this stimulating brainstorming
discussion; it has been proved to be a collage of very interesting,
experienced and in-depth views where you never know what path is going
to be followed next

On Apr 21, 6:51*pm, nikosv <nikos... (AT) gmail (DOT) com> wrote:
P.S. the Guardian group would have been benefited by reading this
stuff, even change their mind ??

On Apr 16, 11:34*am, nikosv <nikos... (AT) gmail (DOT) com> wrote:
those damn statistics...

http://www.guardian.co.uk/media/2011...ebsite-popular

On net wrote:

I'm sure you know at least as many other products not called Oracle as I
do, but to be clear, I can't suggest "something else". There are a few
products that lean in the right direction IMO, but they are too few, too
late, and too "not Oracle".

My point was just that it's unremarkable that a conventional SQL
database isn't working for CMS (nor a lot of other things). They have a
complex problem that involves very complex relationships between
facts. That would always be a challenge. But to make it almost
intractible in this case, the facts need to be expressed in terms of
complex values. (That is, the values they really want to work with are
more high-level than SQL supports. Most SQL products supports numbers,
strings, dates, and not much else.) So they are forced into faking out
atomic values using rows in yet more tables. That's a whole
extra level of unnecessary complexity. (Don't get me wrong; I love
designs that clearly reveal natural complexity. What I hate is
products that force me to create designs with unnecessary complexity.)

Sadly we all end up doing that kind of thing so often I don't think we
really notice how badly it sucks. We assume that's the way the
relational model insists it has to be done. No wonder non-SQL DBMSs
look attractive.


The SQL problems (as defined by me) are many, but for now I'm focusing
on the one I've described above: the misguided idea embedded in every
mainstream SQL product that data types are not allowed to be much more
complex than what the bare hardware supports.

We probably all know the very old grumble (particularly from
OO programmers) about how using a relational/SQL database is like
driving your car home, taking it apart, putting the parts on a shelf in
the garage, and then the next day reassembling it before you can drive
off. It was (and still is) a valid gripe and many kinds of applications
really do suffer because of it.

I find this very plausible too. My argument is only that they would
sooner or later hit the limit of what mainstream SQL DBMSs will allow.
A clean start always helps, but I speculate that they'd end up with a
less awful solution not a really clean one.

I agree 100%. Arguing that there is now a new and better product that
your predecessors had no chance to use is a way easier sell. It offers
everyone a fig-leaf.

That'll be the day!! :-|

I'm not sure what you mean by a query cache. I suppose you mention
cacheing because speed is a problem. Cache works when loads are
"bursty". If your load really is bursty, fine. But if it's not, then
the steady-state limit is exactly what it is without a cache. (Your
toilet tank works exactly the same way; use it often enough and you get
the same flow rate as from the tap.)

But that's a bit of a digression. In my (reasonably well-informed)
opinion, the performance problems of all conventional SQL database
systems arises out the vast number of round-trips the applications
make to get the parts to reassemble the figurative car I was
mentioning above. Further delays are incurred because in most products
rows are literally physical records. To read an attribute you read the
whole record. To read an object you have to read rows from here and
here and here and... There is no fundamental need for that. If you
could have a "car" datatype it would be one read. (VectorWise is one
dazzling example of what happens when you get away from the
row-as-a-record model.)

Well, first off that does nothing to eliminate the unnecessary visible
complexity of the physical model, and secondly even VectorWise would
struggle with a database like that.

I'm not saying that doing all those things faster is not
desirable--VectorWise exists *because* they're so desirable. But even
VectorWise has a sweet-spot, a scale of problem you have to reach,
and below which it just doesn't buy you anything. VectorWise really
screams when you give it a few complex queries on massive amounts of
data. But if you peck it to death with a blizzard of trivial queries on
small amounts of data it will struggle like any other conventional SQL
database.

What would be nice is is a better approach to data types in SQL.

Better late than never I hope! :-)

--
Roy

UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Register at http://www.regonline.co.uk/ukiua2011