since it is an independent feature, you can index in parallel with other reads
Thank you, Ville! I think I'll stick to the tdb_cursor_next() approach over a time filtered cursor. The index sounds very appealing to use, although I would resist to use it for now, not beying available with the standard API (and calling tdb in another process is a pain). But would consider the approach from tdb command line for the 2nd iteration - or a hybrid one in which events are streamed from tdb through a "message bus" to my application - this would also be feasible. Best regards, Marius
also, is there a way of using ldc for compiling the code? When I try it, I get an error about
/usr/bin/ld: .dub/obj/TrailDB.o: relocation R_X86_64_32 against symbol_D9Exception7__ClassZ' can not be used when making a shared object; recompile with -fPIC`
Hey @rrampage, I'm not the person who wrote the TrailDB D bindings though I have used them in our other private company repos. I can't share those repos... but if you have questions on how to use the interface I can help. I've only used dmd and don't know much about ldc. It looks like a linking issue -- this tutorial explains linking and the need for the
-fPIC flag: http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html. dmd calls gcc and perhaps supplies the -fPIC flag automatically, while perhaps ldc does not?
Hey yall, not sure if you know but the travis build is failing rn, looks like a waf issue
https://travis-ci.org/traildb/traildb
https://travis-ci.org/traildb/traildb
@rrampage My company (AdRoll) uses tdbs in a variety of places, both trck and the C API. But the project I am most familiar with uses the C API directly via the D bindings. In this project we iterate over 30 days of tdbs (each holding one day of data) keeping track of per-cookie information in memory with D associative arrays... so in particular we don't merge tdbs (side note: This task was set up in the early days of tdb so if you want to do something like this you should try trck first). I don't have familiarity with merging tdbs, and I don't believe there is a D binding for the merging functions. But it should be possible to add a D binding for the relevant C functions -- if you end up doing so you're welcome to add them via PR to the traildb-d repo :)
able*
At my company we have around 40 million events daily coming into Kafka. As of now, we have set up hourly aggregation on each Kafka consumer after which we do an aggregation of all generated tdbs. The reason we are doing the same is because the tdb_cons is not threadsafe. Is there a better way to do this i.e directly write to a single tdb from multiple kafka consumers (all on same machine)?
you can write to a single tdb too but you have to take care of locking by yourself so multiple threads don't access the same tdb_cons handle concurrently
you could have a tdb endpoint that receives data from all kafka consumers with a small in-memory buffer of events for each consumer. After the buffer is full, you lock tdb_cons and flush the buffer to tdb.
you should get less lock contention with this buffering approach than what you would get if you wrote events one by one to tdb_cons concurrently
depending on your load pattern, it may or may not make a difference
Hello, reading this article https://dev.to/rhymes/adventures-in-traildb-with-millions-of-rows-python-and-go left me with question, why index creation and usage is not available via API?
it is not too hard to use via
ctypes / cffi in Python, if you want to give it a try
{ // add events with timestamps 1 and 2 to a.tdb
tdb_cons_init
tdb_cons_open
tdb_cons_add
tdb_cons_finalize
tdb_cons_close
} // running "tdb dump -i a.tdb" at this point in time will list events with timestamp 1 and 2.
tdb_cons_init
tdb_cons_open
tdb_cons_add
tdb_cons_finalize
tdb_cons_close
} // running "tdb dump -i a.tdb" at this point in time will list events with timestamp 1 and 2.
{ // add event with timestamp 3 to a.tdb
tdb_cons_init
tdb_cons_open
tdb_cons_add
tdb_cons_finalize
tdb_cons_close
} // running "tdb dump -i a.tdb" at this point in time will list only the event with timestamp 3, the first two above (with timestamp 1 and 2) are gone.
tdb_cons_init
tdb_cons_open
tdb_cons_add
tdb_cons_finalize
tdb_cons_close
} // running "tdb dump -i a.tdb" at this point in time will list only the event with timestamp 3, the first two above (with timestamp 1 and 2) are gone.
Is the order of the APIs I am calling OK? If yes, do you have any ideas why after writing the event with timepstamp 3 .. the previously written event will no longer be displayed?
tdb_cons_open always creates a new, empty tdb. If you want to add previous events to a new tdb, open the second tdb with a different name and use tdb_cons_append to add the events of a.tdb there
So my goal is to add events to the same tdb file. OK, so I would then need to call tdb_cons_open() only the first time. What about the following times (so after a tdb_cons_finalize + tdb_cons_close), in case I want to add events again.. what API sequence shall be used to open an already existent tdb for writing? Is it a mix of reading + writing APIs? (like tdb_init, tdb_open, tdb_cons_add, tdb_finalize, tdb_close)
I want to create traildb file pre day.but if i want to focus on visitor level,it is hard to use . I saw multi-cursor ,but it seem to on event level, specially when the same visitor has action on different traildb files. Can anyone provide some suggestion ?
another option is to merge the daily tdbs to a single big tdb before analysis
Hi, @tuulos thinks for help!
I had overviewed api in https://github.com/traildb/traildb/blob/master/doc/docs/api.md. these are tdb_multi_cursor_(new|free|reset) and tdb_multi_cursor_next and tdb_multi_cursor_next_batch.the *next* method is returning events.So if i terating over a single primary key,I have to merge it on visitor_id first,just like:
visitormap = {}
for(event in cursor){
visitorid = event.key
visitormap[visitorid] = append(visitormap[visitorid],event)
}
// THEN do work
for((visitorid,events) in visitormap){
// DO SOME WORK
}So I need to iter the data one time and hold it.It takes time and space.
Is it a better way to do such thing ?
Hi Ville and thanks for the info. Based on your help, I am now evaluating the best approach for my use-case, in which I have frequent (1-5 seconds) write and read operations, spanned over large periods of time. So for the use-case when the merging of two traildbs is done more frequently (say a tiny traildb is merged frequently -each 1-5 seconds- into a larger traildb, which is MB to GB large), are there read/write performance penalties (IO and/or CPU) with this approach, which would rather make it not worthwhile in comparison with the other approach you suggested, where several traildbs are maintained instead?
Hey guys. Neat library! So I am looking for solutions to log user generated events, but IIUIC, traildb doesn't address the problem os storing the data when it's generated, rather focusing on building a queriable archive on already existent data. any suggestions on where to look instead? How do most people do? Use relational datbases and generate archives periodically?
Hi @plainas, I just started using traildb recently and wished to have the same storage capabilities you were describing above. There are probably several ways, it depends on your use-case and requirements. For my use-case, the solution was to open a small tmp DB and write the most recent events to it, then merge this tmp DB to the "main DB". Note: from my understanding, the tmp DB -as any traildb DB- can be queried only after the DB is "finalized"; and once finalized, one can only merge it into another DB. Alternatively, if immediate persistence is not required, one could place the tmp DB on a RAM disk to gain some speed (or cache the "most recent" events in RAM -and query them outside tdb- before persisitng them on disk in a DB). I wished tdb offered a way to store and query events which are not yet in a finalized DB. Still I am curious to learn how others approached the challenge.
Maybe an extra abstraction transparently wrapping both traildb and something else for the data on the tip maybe redis or something. It's a pitty... traildb looks really cool but the design choice of not including writing functionality is a big deal.
I know at least one system which authors made the same design decision for the storage format: Druid (druid.io). But still the system in the whole accept querying even the most recent data. The real-time ingestion tasks accept and collect rows on the (java) heap in a raw, not optimized format. Only after enough data has been collected, it builds a DB file (called segment in Druid parlance) and stores it on the disk. Before the persist data is queryable in the raw format. A simple java Map plays the role of this "temporary DB".. The number of rows kept in memory don't have to be large, it can be in 100K rows range not being that much of a pressure on memory. The small segments saved to disk are already queryable. After some time passed, ingestion task merges the small segments into large one and hands it over the finalized segment to query layer. I believe a system based on TrailDB could follow a similar approach. Can't wait to see if someone implements such a TrailDB-based database :)
the use cases I have been working with this far have been ok with hourly / daily data, so I haven't had need to implement in-memory caching