3 ms·

Ehhhh....that sounds like you're defining big data as distributed data. Hadoop and Cassandra lend themselves to distributed nodes, but you can also use them wi

by dsacco 9y ago

Ehhhh....that sounds like you're defining big data as distributed data. Hadoop and Cassandra lend themselves to distributed nodes, but you can also use them without that. Or you can use solutions that work well with "big data" that aren't as opinionated about it, such as HDF5. I guess the point is this: if I have 20TB of timeseries data on a single machine, and I have 20GB incoming each day, do I get to say I'm working with "big data" yet? EDIT: My other complaint with this definition (perspective, really) is that it predisposes you to choose distributed solutions when you really do have "big data", which is not ideal for all workflows.

xyzzyz 9y ago
If you have 20TB of data on a single machine, you're better off with just Postgres 90% of the time. If you predict you're going have more data to fit on a single machine by the end of the year, then it makes sense to invest in distributed systems.
- dsacco 9y ago
  Okay, why? If you can sell me on that I'd be eager to change my workflow. For reference - this is entirely timeseries financial data and PyTables. For basically everything else I use postgres.
  - dintech 9y ago
    Definitely stick with HDF5 and Python for what you're doing. Postgress doesn't lend itself well to timeseries joins and queries in the same way that a more time series specific database like KDB+ would. The end result is most likely that you'd be bringing the data from a database into python anyway, probably caching in HDF5 before using using whatever python libs you want to use. You could alternatively bring your code/logic to the data using Q in KDB+, but there will be a learning curve and you will have to code for yourself a lot of functionality that just isn't available in library form. The performance will be a lot better though.
pps43 9y ago
There are many examples of small data that is distributed, so distributed data is not necessarily big. But big data has to be distributed simply because there is no single computer big enough to hold all of it.

by dsacco 9y ago

xyzzyz 9y ago

If you have 20TB of data on a single machine, you're better off with just Postgres 90% of the time. If you predict you're going have more data to fit on a single machine by the end of the year, then it makes sense to invest in distributed systems.

dsacco 9y ago
Okay, why? If you can sell me on that I'd be eager to change my workflow. For reference - this is entirely timeseries financial data and PyTables. For basically everything else I use postgres.
- dintech 9y ago
  Definitely stick with HDF5 and Python for what you're doing. Postgress doesn't lend itself well to timeseries joins and queries in the same way that a more time series specific database like KDB+ would. The end result is most likely that you'd be bringing the data from a database into python anyway, probably caching in HDF5 before using using whatever python libs you want to use. You could alternatively bring your code/logic to the data using Q in KDB+, but there will be a learning curve and you will have to code for yourself a lot of functionality that just isn't available in library form. The performance will be a lot better though.

pps43 9y ago

There are many examples of small data that is distributed, so distributed data is not necessarily big. But big data has to be distributed simply because there is no single computer big enough to hold all of it.