As mentioned in previous posts, I have some use cases for MonetDB, which act on tables with a billion rows. MonetDB works fast and stable on straight SELECT statements or aggregates on single tables Problems occured when doing big joins, which should produce a result set of 30 rows only, but running hours before failing. SELECT tbl1.*, tbl2.* FROM tbl1, tbl2 WHERE tbl1.xid = tbl2.xid AND tbl1.pk = 12345678 (same behavior, if written with JOIN explicitly) So I am wondering, if I can help MonetDB with partitioning or sharding. Asked already here: https://www.monetdb.org/pipermail/developers-list/2014-October/004325.html What is the state regarding manual partitioning? During last weeks I saw significant acceleration with sharding on other DBMS. Is there anybody, who can give some introduction or share experiences with sharding on MonetDB? 3rd party tools? What ist the maximum number of tables within a MonetDB database? What is the estimated overhead of a single table, multiplied a million times? Thank you Robert
Hi Robert, Could you possibly check whether the join itself or the projection is the problem? The result is only 30 rows, but how many columns? To do so, replace the * in the select clause by a single column name, e.g., xid. If that works fast, the join itself is less of a problem. Further: how does your query fail, I.e., what's the exact error? Which version of MonetDB are you using and on which OS and what kind of hardware are you running? Thanks! Best, Stefan On January 21, 2015 12:02:59 AM CET, gms_xy@gmx.de wrote:
As mentioned in previous posts, I have some use cases for MonetDB, which act on tables with a billion rows. MonetDB works fast and stable on straight SELECT statements or aggregates on single tables
Problems occured when doing big joins, which should produce a result set of 30 rows only, but running hours before failing.
SELECT tbl1.*, tbl2.* FROM tbl1, tbl2 WHERE tbl1.xid = tbl2.xid AND tbl1.pk = 12345678
(same behavior, if written with JOIN explicitly)
So I am wondering, if I can help MonetDB with partitioning or sharding.
Asked already here: https://www.monetdb.org/pipermail/developers-list/2014-October/004325.html What is the state regarding manual partitioning?
During last weeks I saw significant acceleration with sharding on other DBMS. Is there anybody, who can give some introduction or share experiences with sharding on MonetDB? 3rd party tools?
What ist the maximum number of tables within a MonetDB database? What is the estimated overhead of a single table, multiplied a million times?
Thank you
Robert
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- | Stefan.Manegold@CWI.nl | DB Architectures (DA) | | www.CWI.nl/~manegold/ | Science Park 123 (L321) | | +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
Hi Distributed joins are notoriously expensive unless both operands have been sharded on the join column. Which version of MonetDB are you using? regards, Martin On 21/01/15 00:02, gms_xy@gmx.de wrote:
As mentioned in previous posts, I have some use cases for MonetDB, which act on tables with a billion rows. MonetDB works fast and stable on straight SELECT statements or aggregates on single tables
Problems occured when doing big joins, which should produce a result set of 30 rows only, but running hours before failing.
SELECT tbl1.*, tbl2.* FROM tbl1, tbl2 WHERE tbl1.xid = tbl2.xid AND tbl1.pk = 12345678
(same behavior, if written with JOIN explicitly)
So I am wondering, if I can help MonetDB with partitioning or sharding.
Asked already here: https://www.monetdb.org/pipermail/developers-list/2014-October/004325.html What is the state regarding manual partitioning?
During last weeks I saw significant acceleration with sharding on other DBMS. Is there anybody, who can give some introduction or share experiences with sharding on MonetDB? 3rd party tools?
What ist the maximum number of tables within a MonetDB database? What is the estimated overhead of a single table, multiplied a million times?
Thank you
Robert
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
participants (3)
-
gms_xy@gmx.de
-
Martin Kersten
-
Stefan Manegold