Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am new to cassandra. I have to write an application that uses cassandra. I wanted to know which one will be better for me so that i will not face much problem in future. Which api should i use for my application.
Sunil, you're addressing a reasonable question, and I think it's wholly appropriate that you've asked it before coding away at a problem. You might reach a more widely accepting audience if it were phrased something like, "What are the pros and cons I should look for between these two approaches to help me decide between them?"
The Hector client supports a programmatic interface for communicating with Cassanda, as well as a way to parse CQL statements, so your choice isn't necessarily between Hector and CQL, but more like programmatic vs. CQL, or a combination of the two. You could face that same question even if choosing between Hector and Astyanax clients.
Reasons to choose CQL:
CQL is easy to store, retrieve, and compare revisions.
CQL is easy to read and reveiw, especially as DDL.
CQL is easy to log for troubleshooting and auditing purposes.
Developers with a history of RDBMS may acclimate more quickly to CQL, reducing training time or increasing a pool of candidates for hire.
Community development is trending toward JDBC-like handling of CQL.
Reasons to choose Programmatic:
[AMENDMENT]
It appears some of my knowledge was outdated. Based on jbellis' comment (the Jonathan Ellis, I presume), CQL is currently more performant than thrift, and also supports prepared statements. I'm at a loss for a good argument against a CQL-based approach.
Another completely different option is playOrm so that you can do joins with no limitations. playOrm allows you to do "scalable JQL" which looks like the below. You only need to decide how to partition your data.
#NoSqlQuery(name="findJoinOnNullPartition", query="PARTITIONS t(:partId) select t FROM TABLE as t INNER JOIN t.security as s where s.securityType = :type and t.numShares = :shares")
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need a very lightweight and persistent key/value-store in Java.
The amount of data is very very low and it should be very simple (getter and setter and all can operate on strings).
So I think of using some small NoSQL-DB or even giving some integrated collection a serializer/deserializer to the filesystem.
But I think NoSQL is a overkill and I hope a persister also exists for such a simple requirement.
Whats the best approach here? Any ideas?
You can either implement your own thing if it is a simple key-value string. (Have a look at Java's Properties class too in case it suits your requirements).
If your requirements are slightly more complex have a look at the embedded lightweight databases you can use. Maybe BerkleyDB might work for you. There are quite a number of others if you do a bit of search.
Also think about what you actually need to do with the data. Do you need to query it (so it needs to be indexed?) or do you just want to load it back all into memory? (in which case using a simple JSON or YAML text format would also suffice.)
Most Map<String,String> can be serialized. So for example look into https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html
there you find Serializable. Under that point information to help yourself solve the Problem.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I had been reading two books on JAVA and while covering data structures, I started to do some online research with regards to "QUEUE" implementation. I have an extensive background in FLEX, however ACTIONSCRIPT isn't comparable to advance languages.
Lets say if I was on a job interview and asked to implement a Queue of Object, how should I pursue it as? I am not looking for code help here, I would like to what would you quick answer be? I have been to Java online docs and do understand there are 13 known implementing classes, and "LinkedList" is one of them.
Google search has return more results with "LinkedList" implementation code than any other.
My apologies if you find this question to be rubbish or pointless in anyway.
Oracle's Java online doc ref:
Do you know what the concept of a queue is and how it differs from a stack (closely related data structure)? If so, you should be able to think of multiple ways to implement it.
Which is best depends on the exact requirements of the task it's being used to address.
So the right response to that interview question is not to start coding but to ask them for more information about the requirements your implementation has to address. Performance? Memory size? Multitasking? Any limits on maximum queue depth, eg to guard against things like a DOS attack? What's being enqueued -- objects, primitives, other? Specific kinds thereof? Parameterized type? Are there any values which should be discarded (maybe null shouldn't be enqueued)?
Knowing the requirements, you should be able to judge which answer is appropriate. Starting coding without asking the requirements is immediately going to earn you a demerit.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a query which returns thousands of records (at some point it will). In that query I have some like this
Case when column in(:params1)
then :param2
when column in (:params3)
then :param4
when column in(:params5)
then :param6
when column in(:params7)
then :param8
END ABC
Now the question is what is better to do this in the query or return the column value and do the if\else in the pojo? And why? I tried testing it but currently don't have that much data.
Usually it is better (both because of performance and complexity) to let the database do as much work as possible for you. Doing the work in your application is likely to incur more network traffic than is necessary (which would decrease performance) and the code would have to contain all the nasty logic in it which would add complexity.
Also remember to avoid premature optimization. Try to avoid fixing problems that you don't have yet.
I would recommend letting the database do the work.
Returning thousands of records to the middle tier, operating on them, and shoving the result back into the database makes no sense to me. Why do all that network back and forth?
If you are truly processing that many records, I'd recommend considering letting the database do the work. No network traffic that way.
If not possible, you should make sure you truly need all those records. I'm betting you only think you do.
Writing queries this way seems like another bad idea to me.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What is the general guideline/rule for filtering data? I am accustomed to seeing filters in an SQL statement in the WHERE clause, although there are occasions that filters introduce complexity to the SQL, making it massive and abit hard to read on first glance for intermediate developers, but well-written ones that look complex are well-tuned and optimal. Filtering can also be done in Java, but that of course has a drawback where unfiltered data from SQL can be huge and loading it in memory only to filter it out may be wasteful. Of course there are cases where you have no choice but to filter in Java if you have several datasources as dependencies that the filter requires.
Filter on the backend (sql), whenever possible. If that makes the query too complex for a junior developer then so be it. While clarity of code is important, you shouldn't make design decisions based on how well a junior developer will understand it -- its sufficient that he be able to use it.
This is particularly the case when talking about different layers, your junior developer might not know any SQL, would you then avoid a SQL backend entirely?
Write your SQL to be as clear as possible (without sacrificing performance), but do so with the expectation that the person maintaining it will be familiar with SQL and how it should be used. When crossing layers like this, a little "easier to understand" can really kill your performance (pulling data back from the db in order to update it, can take thousands of times longer than a update on the DB, inappropriate use of a cursor can be expoentally worse than a set based solution).
If the data is already in the DB, then it makes more sense to do the filtering within it, since the RDBMS will be optimized for this kind of work. If the filtering can be confusing to novice and intermediate developers, why not hide it in a view, and only grant access to the view, to the users in question?
I guess there are no definite answers to it. It depends of individual use case. Both filtering in java as well as SQL can be applicable depending on the application under consideration.
As you mentioned, filtering in SQL can make the queries complex and and costly. But at the same this can be improved using database tuning, putting appropriate indexes, table partitioning etc. This is specially the case where in the database design is still evolving and you can do these type of changes.
if you are working on a system whose database is already designed and you have hardly any scope for significant changes (and hence not much query/database optimization), in this case filtering in java is better option.
It all depends on specific use case.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
At my work place, we use DAO pattern to hancle any sort of database operation. It hides bulky statements from programmer. Programmers need to write sql query and logic to handle output data. BaseDao handles all sort of operation and return output in required format.
I found that this class is not perfect. I added the code to control number of connections and to handle connection issues like slow connectivity, no connectivty, number of atttempts for connection etc.
But I would have to add more code to support advance feature of JDBC like providing/accessing binary data, Handling resultsets returned from SPs etc.
Is there any Java Framework or group of classes which can cover many of the database operations?
Please suggest.
I think that you are looking for Java Persistence API. It's a Java EE specification and Hibernate is the most popular implementation.
You could try Spring DAO instead. They have a nice template pattern for handling resultsets.
Or you can take another step step back away from JDBC and use Hibernate.
Spring Data JPA does even more abstraction than the other suggestions people have made. With that and Hibernate you don't even need to write queries unless it's a complex operation you need to perform.