Appreciate your thoughts Tony,
in our DW there are composite keys, 500K of them say per customer
to produce a report for which the client program needs to page
through the entire set collecting data as it pages through yet to
probably another desktop db.
At this point the purpose of having a NoSQL has been defeated.
On 06/26/2013 05:21 PM, Tony Anecito wrote:
Interesting you think
NoSQL does not fit into large volumes of data, That is what
it is touted to do.
I have heard PK's are
needed but remember that is what the "key" column is for I
thought and composite key support is there also.
The only issue I see
is the all that duplicate data and a need to keep it in
sync. So for example if the movie title "Superman" changed
to "Superman the Man of Steel" you have to go change all
those duplicate values. An easy problem to solve but the
data modeler has to get past that. lol
Acid transactions is
the other but I think then the supplier of info has to think
about that one.
I have response times
in my RDMS of several hundred microseconds which is the
really important requirement for me to keep that the same or
Just some thoughts on
Yes, in some scenarios (e.g. a DW), e.g.
absence of proper PKs or indexes (just too hard
to envision, you need to think of future queries
1st) getting thru large volumes of data makes
NoSQL IMHO hard to fit in.
But you have other choices:
1) pagination or
2) slice queries.
Both of that is covered here:
Hope that helps.
Sent: Wednesday, June 26, 2013
Subject: Re: Creating an "Index"
Actually that is what I did. I did that in my
RDMS data model. In Cassandra or NOSQL without
join or nested selects I have to do two
queries. Also, since batching is not supported
on the server side which makes the performance
I just started learning Cassandra but I am
learning fast and there are some challenges
when moving to a new data model driven by
On Wed, Jun 26, 2013 at 10:20 AM, Tony
> Never mind I figured it out. I
found it via a search for Secondary
In general unless you actually need
atomic update of the row and its
secondary index, you are probably better
off creating your own pseudo
secondary index column family.