Well suited: To most of the local run of datasets and non-prod systems - scalability is not a problem at all. Including data from multiple types of data sources is an added advantage. MLlib is a decently nice built-in library that can be used for most of the ML tasks. Less appropriate: We had to work on a RecSys where the music dataset that we used was around 300+Gb in size. We faced memory-based issues. Few times we also got memory errors. Also the MLlib library does not have support for advanced analytics and deep-learning frameworks support. Understanding the internals of the working of Apache Spark for beginners is highly not possible.
If you need a SQL-capable database-like solution that is file-based and embeddable in your existing Java Virtual Machine processes, Apache Derby is an open-source, zero cost, robust and performant option. You can use it to store structured relational data but in small files that can be deployed right alongside with your solution, such as storing a set of relational master data or configuration settings inside your binary package that is deployed/installed on servers or client machines.
Apache Derby is SMALL. Compared to an enterprise scale system such as MSSQL, it's footprint is very tiny, and it works well as a local database.
The SPEED. I have found that Apache Derby is very fast, given the environment I was developing in.
Based in JAVA (I know that's an obvious thing to say), but Java allows you to write some elegant Object Oriented structures, thus allowing for fast, Agile test cases against the database.
Derby is EASY to implement and can be accessed from a console with little difficulty. Making it appropriate for everything from small embedded systems (i.e. just a bash shell and a little bit of supporting libraries) to massive workstations.
If the team looking to use Apache Spark is not used to debug and tweak settings for jobs to ensure maximum optimizations, it can be frustrating. However, the documentation and the support of the community on the internet can help resolve most issues. Moreover, it is highly configurable and it integrates with different tools (eg: it can be used by dbt core), which increase the scenarios where it can be used
1. It integrates very well with scala or python. 2. It's very easy to understand SQL interoperability. 3. Apache is way faster than the other competitive technologies. 4. The support from the Apache community is very huge for Spark. 5. Execution times are faster as compared to others. 6. There are a large number of forums available for Apache Spark. 7. The code availability for Apache Spark is simpler and easy to gain access to. 8. Many organizations use Apache Spark, so many solutions are available for existing applications.
Spark in comparison to similar technologies ends up being a one stop shop. You can achieve so much with this one framework instead of having to stitch and weave multiple technologies from the Hadoop stack, all while getting incredibility performance, minimal boilerplate, and getting the ability to write your application in the language of your choosing.
SQLite is another open-source zero-cost file-based SQL-capable database solution and is a good alternative to Apache Derby, especially for non-Java-based solutions. We chose Apache Derby as it is Java-based, and so is the solution we embedded it in. However, SQLite has a similar feature set and is widely used in the industry to serve the same purposes for native solutions such as C or C++-based products.
Being Open source, the resources spent on the purchase of the product are ZERO.
Contrary to popular belief, open source software CAN provide support, provided that the developers/contributors are willing to answer your emails.
Overall, the ROI was positive: being able to experiment with an open source technology that could perform on par with the corporate products was promising, and gave us much information about how to proceed in the future.
