I am saving long Json string into DB , fetching the string from Db and then serializing it for other manipulation is making it slow.
Is there any good solution to do that.
As there was told, you might need to use Documented-Oriented DB, like MongoDB.
If you can't do this, please consider combined data storage: something you may store in RDBMS, something - in MongoDB.
And if it is impossible for certain reasons, please look at binary formats of JSON: Smile or BSON, both of which are supported by various frameworks, such as JSON.Net (article for consideration http://james.newtonking.com/archive/2009/12/26/json-net-3-5-release-6-binary-json-bson-support.aspx)
The best possible way is to use a document oriented database which support json for storage. This way you can query or update part of the long json without fetching or serializing it.
Related
I am reading several tutorials on how to use an SQL database with Cocoa, and it seems quite easy. I already took a look at a few wrappers too, but I can't find anywhere a way to save objects.
Is it correct to conform my model object to the NSCoding protocol, and just save the NSKeyedArchiver as an NSData object into the DB?
Should I do differently? Which is the best way?
You can use NSKeyedArchive too, but is not the best solution imho. Is like storing all data in a platform independent "database" an xml file. It wasn't created for that, it in't optimized for that.
I would create a NSSqlArchieve and map those fields which I want as how I want in native database, because: in different databases you can have custom fields, custom type fields , which myabe improve a select or other database operation. Or you just want to take advatage of some system table/data and can't find a mapping or is to slow or other problems.
NSData can be stored / retrieved to a Blob/Clob, since is binary data.
But all data convert to binary format and store it to database.... why to store there and why not into a file. Database was invented to store and make query from data.
Hi I am new to HBase and I wonder what is the best approach to serialize and store the data to HBase. Is there any convenient way how to transform "business objects" at application level to HBase objects (Put) - transformation to byte[]. I doubt that it has to be converted manually via helpers methods like .toByte etc.
What are the best practices and experiences?
I read about Avro, Thrift, n-orm, ...
Can someone share his knowledge?
I would go with the default Java API and enable compression on HDFS rather than using a framework for serializing / deserializing efficiently during RPC calls.
Apparently, updates like addition of a column to records in Avro/Thrift would be difficult as you are forced to delete and recreate.
Secondly, I don't see support for Filters in thrift/avro. In case you need to filter data at the source.
My two cents .
For a ORM solution, kindly have a look at https://github.com/impetus-opensource/Kundera .
Not sure if this is a silly question but as an application developer that is abstracted from the database via an ORM (in my case I'm using Grails/GORM) what would be the advantages of using something like MongoDB vs something like MySQL ?
Does it really matter?... especially given that I'll be using the GORM API to access my data and will be identifying relationships between my objects.
Thanks!
If all you're doing is storing data that's basically relational in a NoSQL store like MongoDB then you might as well use a proper relational database. The big benefit of the GORM wrappers for the NoSQL stores is that for data that is basically table/column-based you can use GORM, but you can easily access the native store to work directly with the document/graph/column/key-value/etc storage mechanism.
Anything having tree structure is better to store in mongodb, otherwise if data has table structure mysql will be better solution
I want to store and retrieve images to/from database using java beans, which data type should be used for this purpose?
The most conventional approach would be to store the data in a BLOB. That would allow you to read and write the byte stream from Java but wouldn't allow you to do any transformation inside the database.
The other alternative would be to use the interMedia ORDImage type. This provides a great deal more flexibility by allowing the database to do things like generate and return a thumbnail image, to adjust compression quality, etc.
As Grant indicates, LONG RAW (and the character-based LONG) data types have been deprecated so you should not be using them.
I think BLOB is what you are looking for. RAW types are for legacy support so unless you absolutely have to deal with them I wouldn't.
After doing my exercise in school, I use Sqlite to store my data. But there's XML / JSON [ I haven't tried yet, but I prefer JSON because its' simplicity ], they're used to store data too. And they seems popular, there's JSON for C#,C++,py ....
I wonder when to use these ones ? And I'm happy to hear about theirs performance too, I care most about speed ;)
Thanks.
XML and JSON are actually used primarily to transmit data between processes or systems.
I have seen applications that use XML as a database. If you're going to do this, you'll have to break your data down into very distinct, small units that can each be stored in a separate file.
Overall, in my opinion and experience, if performance is your primary concern, file-based data storage in XML or JSON will almost never perform remotely close to an actual SQL relational database platform unless your dataset is extremely tiny.