Overview (*This topic was presented at (SharePoint Saturday Silicon Valley, June 22nd, 2013) Over the years working with SharePoint we all have built out various SharePoint related environments for the purpose of Development. In the past (Prior to SharePoint 2013) we could install MOSS 2007 and SP 2010 right in our Lap Top/Desk top over Windows 7. Alternatively we could spin up a VM over VMWare workstation and run right in our lap top. All of the above combination worked very well and we were on our happy path to build, learn and demo. So initially I did the same with the new SharePoint 2013. But like we all know installing on Client OS (Win 7/8) is no more supported. Next step was to start with a local VM in VMWare Workstation. Sure I got all of that. But I had faced a significant processing and memory problems. First for lack of processing and memory capabilities on a Lap Top type of device and second the SharePoint 2013 platform now introduces quite number of services that are processor and memory hungry. Click here to view full post!

Guest post by Kayvan Iradjpanah, an attorney with Littler Employment & Labor Law Solutions Worldwide The traditional boundaries of the workplace are quickly becoming a relic of the past due to... Visit site for full story...

On June 17, @shrmnextchat chatted with Kevin Mottram (@KevyDMottram) and Alex Alonso (@shrmresearchVP) about "Can Holacracy Work at Work." In case you missed this excellet chat on the Holacracy operating model, you can see all the great tweets here and below:    [View the story "#Nextchat RECAP: Can Holacracy Work at Work? " on Storify]  ...

Visit site for full story...

Overview In this blog, I will be discussing about NoSQL databases, how different are NoSQL Databases compared with Relational databases, different types of NoSQL Databases. Introduction Contrary to their name, NoSQL databases are not databases without SQL (Structured Query Language) capabilities nor are they a single product or technology. NoSQL databases are a group of data storage and manipulation technologies that do not have relational capabilities. Some of the NoSQL databases, in fact, do permit querying in SQL or SQL-like languages but they do not have fixed schemas. So, a more appropriate name for these set of products could be NoREL (No Relational) or the acronym NoSQL can be thought of as a short hand for ‘Not Only SQL’. Traditionally, Relational Databases (RDBMS) have been used to store data required for processing in applications. However, over the past couple of decades, as data started exceeding the processing capacity of traditional databases, there became a need to have alternative storage and retrieval mechanisms. Coupled with the advent of Big Data, the problem of having to process large amount (Volume) of unstructured data (Variety) in real-time (Velocity) became even more acute. Since Relational Databases could not address this need, it led to the popularity and prevalence of NoSQL databases. NoSQL databases provide us with mechanisms to store and retrieve data for Big Data Analytics along with capabilities for schema-less data structures, horizontal scaling, high availability and alternative query methods. Differences between Relational and Non-Relational Databases (NoSQL Databases) Relational Databases are set theory based systems where data is stored two-dimensional tables whereas NoSQL databases are a set of technologies that were conceived to solve the challenges of distributed and parallel computing in scalable Internet applications. Relational Databases use schemas for storing their data (every row of data in a table has the same set of information) whereas there are no set schemas in NoSQL databases. NoSQL databases provide alternate mechanisms for storing data such as a Key-Value pair or a Graph. (More on that later) Relational Databases guarantee that all transactions will conform to ACID (Atomicity, Consistency, Isolation and Durability) properties whereas NoSQL databases do not provide any such guarantees. In fact, NoSQL databases only guarantee Eventual Consistency, meaning that the data item will eventually be consistent with the latest updated value. Relational Databases are useful where the data is structured and largely uniform whereas NoSQL databases are well suited to process huge volumes of unstructured or complex data that’s required to scale out horizontally. Considerations for Data Storage Eric Brewer from University of California, Berkeley presented a theory known as the CAP Theorem which identifies three important considerations for building applications in a distributed environment - Consistency, Availability and Partition Tolerance (hence the name - CAP Theorem). Further, it states that, in distributed applications, you can only guarantee two of the above three considerations simultaneously.  While typical Relational Databases guarantee Consistency and Availability, the architecture of NoSQL databases are more oriented towards either providing Consistency and Partition Tolerance or Availability and Partition Tolerance. Nathan Hurst has a nice visual representation of where the various available data stores lie on the CAP Theorem considerations. Different types of NoSQL Databases Key-Value Databases This is the simplest form of NoSQL Databases. A Key-Value (KV) store is implemented using a hash table (or a map) where a unique key points to particular value or data. Due to their simplicity, Key-Value databases are very efficient for accessing data. Some of the common examples of Key-Value databases are Redis, Riak and Voldemort Column-Oriented or Wide Column Databases The column-oriented databases are an extension of Key-Value data stores where data from a given column is stored together. The columns are grouped into column families and are stored as a key-value pairs within the respective families. The column families act as a key for the columns it contains and the row key acts as the key for the data store. HBase and Cassandra are two well-known examples of a Column-Oriented Database. Document Databases In document databases, the data is stored as documents represented in JSON or XML format. These documents are a collection of key-value pairs and its possible to have a nested structure of these key-value pairs within a document. Document databases can be indexed on its unique identifier or any other key within the document. These documents are highly flexible and provide means for adhoc querying and replication. Couple of major open source document databases are - MongoDB and CouchDB. Graph Databases Graph databases, as their name suggests, are based on the Graph Theory and provide means of dealing with highly interconnected data. In these databases, data is represented as nodes and then relationships are defined between these nodes. Using these relationships, traversing through the nodes becomes easy and efficient. Neo4J, Polyglot and infiniteGraph are some examples of graph databases. Conclusion Coupled with Relational Databases, NoSQL Databases provide us with another way to store, retrieve and manage data, specifically unstructured data. Its important to realize that one single type of data store (Relational or Non-relational NoSQL Databases) will not be able to address all of your data requirements. There are various flavors of NoSQL databases available and its best to understand your data requirements, the usage patterns, the service level agreements and the available resources before making a decision on the data storage setup. In the coming blog posts, I will delve deeper into each of the categories of NoSQL databases with specific examples using some of the popular products. This should help in understanding the capabilities and the feature sets provided by the various NoSQL databases.  

A New TriNet Survey Outlines How Your Expense Reporting Process May be Hurting Your Retention If you’re like most businesses on the fast-track to success, you care deeply about your employees and... Visit site for full story...

Do you feel like you need to have all the answers? Most people do.  This need was ingrained in us from a very early age: When we’re in school and the teacher calls on us, we’re supposed to know the answer. The right answer. And we are expected to have ALL the right answers, all the time, for years... All the way through elementary school. Middle school. High school. College.  We’re expected to have the right answers on aptitude tests. Skills tests. Job interviews! But a funny thing happens...

Overview In this blog series, we will discuss the Hadoop ecosystem (with a focus on Hortonworks distribution of Hadoop for Windows Server and HDInsight Service for Azure) - core technologies such as HDFS and MapReduce, Pig (containing a data flow language to support writing queries and dataset transformation on large datasets using richer data structures than MapReduce), Hive (a SQL abstraction on top of MapReduce for more structured data), Sqoop (a tool to transfers bulk data between Hadoop and relational databases), Mahout (an open source machine-learning library facilitating building scalable matching learning software), and Pegasus (a peta-scale graph or data mining system running on Hadoop). Problems with conventional database system In a previous blog article we mentioned that processing big data exceeds the capacity of conventional database systems. While a large number of CPU cores can be placed in a single server, it’s not feasible to deliver input data (especially big data) to these cores fast enough for processing. Using hard drives that can individually sustain read speeds of approx. 100 MB/s, and 4 independent I/O channels, a 4 TB data set would take over 2 days to read. Thus a distributed system with many servers working in problem is necessary in the big data domain. Solution: Apache Hadoop Framework The Apache Hadoop framework supports distributed processing of large data sets using a cluster of commodity hardware that can scale up to thousands of machines. Each node in the cluster offers local computation and storage and is assumed to be prone to failures. It’s designed to detect and handle failures at the application layer, and therefore transparently delivers a highly-available service without the need for expensive hardware or complex programming. Performing distributed computing on large volumes of data has been done before, what sets Hadoop apart is its simplified programming model for client applications and seamless handling of distribution of data and work across the cluster.  Architecture of Hadoop Let’s begin by looking the basic architecture of Hadoop. A typical Hadoop multi-machine cluster consists of one or two "master" nodes (running NameNode and JobTracker processes), and many "slave" or "worker" nodes (running TaskTracker and DataNode processes) spread across many racks.  Two main components of the Hadoop framework are described below - a distributed file system to store large amounts of data, and a computational paradigm called MapReduce. Hadoop Distributed File System (HDFS) Since the complete data set is unlikely to fit on a single computer’s hard drive, a distributed file system which breaks up input data and stores it on different machines in the cluster is needed. Hadoop Distributed File System (HDFS) is a distributed and scalable file system which is included in the Hadoop framework. It is designed to store a very large amount of information (terabytes or petabytes) reliably and is optimized for long sequential streaming reads rather than random access into the files. HDFS also provides data location awareness (such as the name of the rack or the network switch where a node is). Reliability is achieved by replicating the data across multiple nodes in the cluster rather than traditional means such as RAID storage. The default replication value is 3, so data is stored on three nodes - two on the same rack, and one on a different rack. Thus a single machine failure does not result in any data being unavailable. Individual machines in the cluster that store blocks of an individual files are referred to as DataNodes. DataNodes communicate with each other to rebalance data, and re-replicate it in response to system failures. The Hadoop framework schedules processes on the DataNodes that operate on the local subset of data (moving computation to data instead of the other way around), so data is read from local disk into the CPU without network transfers achieving high performance. The metadata for the file system is stored by a single machine called the NameNode. The large block size and low amount of metadata per file allows NameNode to store all of this information in the main memory, allowing fast access to the metadata from clients. To open a file, a client contacts the NameNode, retrieves a list of DataNodes that contain the blocks that comprise the file, and then reads the file data in bulk directly from the DataNode servers in parallel, without directly involving the NameNode. A secondary NameNode is used to avoid a single point of failure, it regularly connects to the primary NameNode and builds snapshots of the directory information. The Windows Azure HDInsight Service supports HDFS for storing data, but also uses an alternative approach called Azure Storage Vault (ASV) which provides a seamless HDFS interface to Azure Blob Storage, a general purpose Windows Azure storage solution that does not co-locate compute with storage, but offers other benefits. In our next blog, we will explore the HDInsight service in more detail. MapReduce Programming Model Hadoop programs must be written to conform to the "MapReduce" programming model which is designed for processing large volumes of data in parallel by dividing the work into a set of independent tasks. The records are initially processed in isolation by tasks called Mappers, and then their output is then brought together into a second set of tasks called Reducer as shown below. MapReduce input comes from files loaded in the processing cluster in HDFS. The client applications submit MapReduce jobs to the JobTracker node which divides and pushes work out to available TaskTracker nodes in the cluster while trying  to keep the work as close to the data as possible. Hadoop internally manages the cluster topology issues as the rack-aware HDFS file system enables the JobTracker to know which nodes contain the data, and which other machines are nearby. If the work cannot be hosted on one of the node where the data resides, priority is given to nodes in the same rack. This reduces the data moved across the network. When the mapping phase completes, the intermediate (key, value) pairs are exchanged between machines to send all values with the same key to a single reducer. The reduce tasks are spread across the same nodes in the cluster as the mappers. This data transfer is taken care of by the Hadoop infrastructure (guided by the different keys and their associated values) without the individual map or reduce tasks communicating or being aware of one another’s existence. A heartbeat is sent from the TaskTracker to the JobTracker frequently to update its status. If any node or TaskTracker in the cluster fails or times out, that part of the job is rescheduled by the underlying Hadoop layer without any explicit action by the workers. The TaskTracker on each node is spawned off in a separate Java Virtual Machine process to prevent the TaskTracker itself from failing if the running job crashes the JVM. User-level tasks do not communicate explicitly with one another and workers continue to operate leaving the challenging aspects of partially restarting the program to the underlying Hadoop layer. Thus Hadoop distributed system is very reliable and fault tolerant. Hadoop also has a very flat scalability curve. A Hadoop program requires no recoding to work on a much larger data set by using a larger cluster of machines.  Hadoop is designed for work that is batch-oriented rather than real-time in nature (due to the overhead involved in starting MapReduce programs), is very data-intensive, and lends itself to processing pieces of data in parallel. This includes use cases such as log or clickstream analysis, sophisticated data mining, web crawling indexing, archiving data for compliance etc. In subsequent posts, we will look at the MapReduce programming model and other aspects of Hadoop in more detail… Coming soon!

Each year, employers pay thousands of dollars into state unemployment tax accounts for unemployment benefits. While some of these costs cannot be avoided, there are several ways in which employers... Visit site for full story...

In 2008, I flew to Chicago for my first SHRM national conference.  I traveled alone and didn't know anyone attending the conference.  I spent every possible minute in session after session.  I was at all the keynote speeches. At the end of each day, I ran back to my room to type up my handwritten notes, read through the daily SHRM newspaer, and catch up on work I was missing while away.  At the end of the conference, I even bought the recordings of all the sessions. I thought I'd re-listen to the ones I attended and also...