On Feb 23, 2015, at 06:33, Gustavo Brian Gustavo.Brian@sunhotels.net wrote:
Hi,
I want to implement a calendar based big table with prices for hotel accommodation with MonetDB. Once I have all the data in the table the performance is amazing but now I'm worried about insert/delete/update performance. I've asking at stackoverflow: http://stackoverflow.com/questions/28122178/monetdb-refresh-data-in-backgrou... and had a nice approach but now I wonder about having a fixed size table because I can approximate the needed records
Hello Gustavo,
With "fixed size table" do you mean tables with predefined and fixed number of tuples? If yes, I don't expect it to make any difference. (as far as I know) MonetDB doesn't have any special feature to support such fixed size table, and hence, no special optimisation neither. I think you can try how well the suggestion at stackoverflow works for your application.
The performance decrease you have noticed is somewhat expected. In this blog, we explain how transaction works in MonetDB: https://www.monetdb.org/blog/monetdb-sql-transaction-management-scheme
Next to Hannes suggestion at stackoverflow, you can also consider using more than one MonetDB server for your application. Say 2 servers: server1 for read queries, server2 for updating queries. once in a while, switch server1 and server2. Let server2 serve read queries, while sync server1 and then let it accept updates. This way, you not only eliminate the concurrency between read and updating queries, you also have better fault tolerance.
We are working on Transaction replication (see end of the blog above). Given the explanation about your application at stackoverflow, this new feature might be very helpful, especially when you need to scale up.
for having a year of data and update them each time I have to: enable/disable, change free units, update prices, ...
I'm afraid I don't understand what you mean here...
Regards,
Jennie
Some of the columns will be used for search: "destination", "date", "category", ... others for refinement: "units", "blocked", ... and others as values for the aggregations: "price", "breakfast", ...
Is a fixed size table a good approach ? Updating the columns used for refinement or calculation will affect performance ?
Thanks,
Gustavo Brian Developer
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list